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PREFACE 


This  paper  documents  the  procedures,  techniques,  and  concepts  that 
I  incorporated  in  the  design  and  implementation  of  a  viable  data  defini¬ 
tion  system  that  is  used  to  prepare  an  extensive  input  data  set  for  a 
large  digital  computer  simulation  program.  The  paper  references  many  of 
the  design  considerations  used  throughout  the  development  process  but  is 
directed  primarily  at  those  persons  who  are  most  familiar  with  the  simu¬ 
lation  program  and  who  will  be  using  this  system  in  the  future.  I  hope, 
however,  that  it  is  written  well  enough  to  be  read  and  understood  by 
anyone  familiar  with  basic  concepts  in  scientific  and  computer  graphics 
applications. 
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this  thesis  project  and  for  his  support  and  guidance  throughout  its 
duration.  Additionally,  I  would  like  to  thank  my  advisor.  Professor 
Charles  Richard,  for  providing  much  needed  advise,  often  needed  reassur¬ 
ance,  and  constant  stimulus  for  completing  the  project  adequately  and  on 
time.  Thanks  also  to  Major  Alan  Ross  and  Captain  Roie  Black  for  their 
critical  support  in  preparation  of  this  document  and  to  Miss  Diane 
Gilliland  for  her  most  valuable  and  professional  assistance  in  typing 
and  collating  the  final  copy. 

Above  all,  I  wish  to  acknowledge  my  most  sincere  appreciation  and 
indebtedness  to  my  wife,  Diane,  and  tw  sons,  Scott  and  Kurt,  for  their 
patience  and  understanding  regarding  my  many  hours  of  absence  during  the 
past  nine  months. 
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ABSTRACT 


The  Air  Force  Avionics  Laboratory  utilizes  a  digital  computer  model 
of  an  air  defense  command  and  control  system  in  its  analysis  programs. 

The  model  is  quite  large  and  requires  an  extensive  input  data  set,  of 
which  approximately  80%  is  used  to  define  the  ground  defense  environment. 
Current  techniques  for  preparation  of  the  input  data  are  totally  manual, 
requiring  many  hours  of  tedious  site  preparation,  data  transcription, 
and  keypunching. 

This  paper  presents  a  completely  new  approach  to  the  preparation 
of  the  ground  defense  environment  data.  A  system  of  three  computer  pro¬ 
grams  is  identified  that  provides  an  automated  process  for  converting 
basic  site  parameterization  data  into  the  required  format  for  input  to 
the  model.  An  interactive  computer  graphics  program  is  the  core  of  the 
✓  system  and  the  principal  vehicle  through  which  all  data  modification  and 
assignment  actions  occur.  State-of-the-art  concepts  in  software  engi¬ 
neering,  data  storage  and  retrieval,  and  man-machine  communication 
techniques  are  incorporated  which  enable  early  detection  of  erroneously 
defined  data,  increase  the  quality  and  timeliness  of  the  final  product, 
and  improve  overall  system  maintainability. 
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I .  INTRODUCTION 


One  of  the  primary  problems  associated  with  digital  computer 
processing  stems  from  the  expectation  that  the  output  resulting  from 
any  particular  process  is  consistently  accurate,  thereby  providing 
meaningful  information.  This  expectation  may  be  based  on  natural  law, 
prior  experience,  or  even  intuition,  but  is  founded  on  the  premise  of 
program  accuracy  and  valid,  error-free  input  data. 

Many  application  programs  require  extensive  input  data  sets.  This 
is  particularly  true  when  the  program  is  used  to  model  a  real-world 
situation  and  a  comprehensive  scenario  definition  is  required.  Then, 
both  scenario  definition  and  evaluation  data  must  be  defined  and  prepared 
in  accordance  with  the  input  formatting  requirements  of  the  program. 

This  paper  will  address  the  concept  of  error-free  input  data  as 
applied  to  an  existing  production  program  called  AADEM.  Of  particular 
concern  are  the  methods  used  to  prepare  the  data  for  input  to  the  program. 
It  will  be  assumed  that  the  probability  of  an  execution  error  caused  by 
incorrect  code  within  the  program  is  minimal.  Under  this  assumption, 
erroneous  output  data  will  be  solely  a  function  of  the  input  data  -  i.e., 
how  it  is  prepared,  how  it  is  entered  into  the  program,  and  the  validity 
of  the  included  parameters.  A  method  of  defining  input  data  parameters 
for  the  model  using  automated  techniques  is  identified.  State-of-the-art 
concepts  in  software  engineering,  data  base  storage  and  retrieval,  and 
man-machine  communication  techniques  are  incorporated  which  enable,  to  the 
extent  possible,  early  detection  of  erroneously  defined  data  and  a  subse¬ 
quent  reduction  in  the  number  of  aborted  or  non-productive  AADEM  simulation 
runs  due  to  improperly  defined  input  data. 


The  remainder  of  this  chapter  will  provide  the  reader  with  a  brief 
description  of  the  target  program,  AADEM,  and  a  statement  of  the  objec¬ 
tives  of  this  project  through  identification  of  a  problem  inherent  in 
the  current  method  of  AADEM  data  preparation.  A  proposed  solution  is 
presented  and  an  outline  of  the  approach  taken  to  implement  the  solution 
is  given. 

The  AADEM  Model 

The  Air  Force  Avionics  Laboratory  (AFAL)  utilizes  a  digital  computer 
model  of  an  air  defense  command  and  control  system  in  its  analysis  pro¬ 
grams.  Called  the  Avionics  Air  Defense  Evaluation  Model  (AADEM),  it  is 
used  to  evaluate  electronic  warfare,  defense  suppression,  and  counter  C3 
technologies,  concepts,  and  tactics  (Kef  7:  79).  The  model  simulates 
aircraft  penetration  into  an  area  that  includes  tactical  and  strategic 
jamming  aircraft  and  hostile  interceptors,  ground-based  weapon  systems, 
and  command  and  control  networks.  The  model  is  very  large,  requiring 
from  1.5  -  1.7  megabytes  of  memory  for  each  run  and  executes  in  batch 
mode  on  the  dual  ITEL  AS-5  Computer  Systems  at  the  ASD  Computer  Center. 

Additional  papers  have  been  presented  concerning  the  implementation 
of  the  AADEM  model  (Ref  4:  76)  ,  graphical  input  techniques  for  the  model 
(Ref  1:  75)  ,  and  flight  profile  definition  for  penetration  aircraft 
(Ref  6:  78)  .  This  paper  will  address  the  problem  of  error-free  input 
data  used  to  define  the  ground  defense  system  and  the  command  and  control 
network  within  the  scenario. 

The  geographic  area  of  interest  containing  these  defense  elements, 
or  sites,  will  be  referred  to  in  this  paper  as  the  environment.  The 
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elements  are  categorically  divided  into  two  types,  strategic  and  tactical, 
and  are  identified  accordingly  in  Table  I.  Surface-to-Air  Weapon  sites 
include  both  Anti-Aircraft  Artillery  (AAA)  and  Surface-to-Air  Missile 
(SAM)  sites.  The  sites  will  often  be  referenced  by  way  of  an  abbreviation 
which  is  indicated  in  the  parenthesis  beside  its  proper  name  in  the  table. 

The  association  of  the  various  sites  is  through  a  command  and  con¬ 
trol  structure  as  indicated  in  Figure  1.  The  primary  distinction  between 
the  strategic  and  tactical  configuration  is  based  on  the  designation  of 
selected  SAM  types  to  either  function.  Of  the  six  unique  SAM's  included 
in  the  model,  three  are  designated  for  strategic  deployment  and  the 
remaining  three  for  tactical  deployment. 

Statement  of  the  Problem 

The  primary  problem  is  that  the  AADEM  model  requires  extensive  input 
data  which  must  be  painstakenly  and  tediously  created  for  each  new  simula¬ 
tion.  Basic  site  identification  data,  already  available  in  machine 
readable  form,  is  manually  plotted  on  large  area  maps.  Additional  site 
characterization  information  and  command  and  control  linkages  are  then 
added  until  the  complete  scenario  has  been  defined.  All  site  parameter 
data  is  then  correlated  and  transcribed  onto  coding  sheets  and  subsequently 
keypunched,  thus  producing  the  AADEM  input  data  set.  Typically,  this  data 
set  consists  of  approximately  10,000  computer  cards  and  the  complete  pro¬ 
cess  has  required  an  approximate  two  man-year  effort. 

Since  the  data  preparation  process  is  entirely  manual,  the  likeli¬ 
hood  of  erroneous  data  scattered  throughout  the  data  set  is  extremely  high. 
This  will,  in  most  cases,  generate  erroneous  or  inconsistent  output  which 


3 


TABLE  I 


Defense  Element  Types 


STRATEGIC 

TACTICAL 

Early  Warning  (EW) 

Battery  (SA) 

Group  Center  (GP) 

Battalion  (BA) 

Headquarters  (HQ) 

Super  Battalion  (SB) 

Ground  Control  Intercept  (GC) 

Division  (DV) 

Airfield  (AF) 

Army  Headquarters  (AH) 

Fire  Control  Center  (FC) 

Surf ace-to- Air  Weapon  (SA) 

may  or  may  not  be  detected  and  could  cause  incorrect  conclusions  to  be 
drawn  on  the  results  of  the  simulation.  Consequently,  a  validation  pro¬ 
cess  is  required  to  verify  the  results  of  each  AADEM  run.  This  process 
can  take  as  long  as  two  man-months  to  complete,  thereby  placing  additional 
overhead  on  an  already  costly  process. 

Proposed  Solution 

The  most  direct,  and  often  the  easiest,  solution  to  any  problem  is 
to  eliminate  its  cause.  This  is  the  approach  taken  in  this  project.  The 
problem,  simply  stated,  is  that  machine  readable  data  is  manually  manipu¬ 
lated  through  several  difficult  procedures  and  then  returned  to  machine 
readable  form.  The  manual  procedures  involved  in  the  process  are  repeti¬ 
tious  and  time  consuming;  two  factors  that  are  highly  conducive  to  hidden 
or  overlooked  errors.  The  solution,  simply  stated,  is  to  minimize  all 
required  manual  data  manipulation  procedures. 


GENERALIZED  COMMAND  &  CONTROL 


Figure  1 .  AADEM  Command  and  Control  Structure 


This  may  be  accomplished  through  the  development  of  a  computer- 
aided  data  identification  system  whereby  the  design  analyst,  or  user, 
can  manipulate  the  site  definition  data  through  the  use  of  interactive 
computer  graphics.  Two  basic  processes  would  be  required.  The  first 
would  convert  the  given  machine  readable  data  into  a  data  base  structured 
for  efficient  interactive  usage.  The  second  process  would  provide  the 
capability  for  the  user  to  easily  redefine  or  modify  existing  site  param¬ 
eter  values.  Validation  of  data  assignments  or  manipulative  procedures 
can  occur  within  the  computer  and  immediate,  informative  feedback  can  be 
presented  to  the  user  either  visually  or  through  narrative  messages  on  the 
graphics  display  screen.  To  be  a  viable  system,  it  must  incorporate  a 
maximum  of  human  engineering  concepts  which  provide  a  continual  stream  of 
definitive  prompts  and  informative  diagnostics.  Above  all  else,  it  must 
accomplish  the  required  task  in  a  more  expeditious  and  efficient  manner 
than  previous  methods. 

The  purpose  of  this  project  is  therefore  as  follows:  to  design  and 
implement  a  viable  data  definition  and  validation  system  that  will  maxi¬ 
mize  the  integrity  of  the  input  data  to  the  AADEM  model  by  means  of 
effective,  easy-to-use  interactive  computer  graphics. 

The  proposed  system  is  called  the  P-Card  Data  Definition  System 
(PDDS) .  The  complete  input  data  set  for  a  typical  AADEM  run  consists  of 
eighteen  functionally  distinct  groups  of  cards.  For  documentation  and 
identification  purposes,  each  group  is  denoted  separately  as  A-Card  data, 
B-Card  data,  and  so  on.  The  largest  group,  comprising  approximately  80% 
of  the  total  data  set,  is  the  ground  environment  data.  This  group  is 
denoted  P-Card  data  -  hence  the  system  name. 
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Approach 


The  approach  taken  toward  implementation  of  the  system  consisted  of 
five  principal  steps.  The  first  step  was  to  obtain  a  complete  understand¬ 
ing  of  current  methodologies  used  to  develop  the  AADEM  input  data  set. 
Through  this,  much  insight  was  obtained  with  regard  to  the  form  and 
availability  of  various  parts  of  the  process,  how  these  parts  interact, 
and  the  overall  requirements  of  the  process.  Also,  identification  of 
problems  inherent  in  current  practice  occurred  during  this  step. 

The  second  step  involved  a  comprehensive  system  requirements  defini¬ 
tion  to  determine  a  complete  understanding  of  the  objectives  that  a  solu¬ 
tion  system  is  to  fulfill.  Included  in  this  step  was  the  identification 
of  those  concepts  that  provide  an  effective  man-machine  interface  within 
the  context  of  error-free  processing  and  some  considerations  for  future 
modifications.  The  results  of  this  step  provided  a  basis  for  the  design 
and  implementation  of  the  solution  system.  Chapter  II  discusses  the 
requirements  definition  process. 

Step  three  of  the  implementation  consisted  of  a  complete  system 
definition  including  the  identification  of  file  structures,  input-output 
techniques,  required  support  hardware  and  software,  and  the  development 
of  a  preliminary  system  user’s  guide.  Chapter  III  will  document  consid¬ 
erations  and  decisions  incurred  during  this  step. 

The  next  step,  step  four,  involved  the  software  development  process 
wherein  FORTRAN  programs  to  create  the  system  data  base  and  to  permit  user 
interaction  with  the  data  base  were  written.  Chapters  IV  and  V  describe 
the  development  and  operation  of  each  of  these  programs. 
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The  final  step,  which  actually  paralleled  much  of  the  program 
development  of  step  four,  incorporated  test  and  evaluation  procedures 
into  the  composite  system.  Results  of  these  procedures  and  recommenda¬ 
tions  for  changes  or  additions  to  the  system  based  on  these  results  are 
discussed  in  Chapter  VI. 

Several  appendices  are  included  which  provide  supportive  documenta¬ 
tion  for  all  processes  outlined  above. 
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The  first  course  of  action  in  the  resolution  of  any  problem  is  a 
complete  analysis  of  existing  methodologies  and  conditions  in  order  to 
determine  the  true  nature  of  the  problem.  This  understanding  is  then 
used  as  a  basis  for  a  system  requirements  definition.  A  requirements 
definition  is  a  careful  assessment  of  the  needs  that  a  system  is  to  ful¬ 
fill  and  provides  limits  for  eventual  system  design  and  implementation. 
That  is,  a  requirements  definition  encompasses  everything  necessary  to 
lay  the  groundwork  for  subsequent  system  development  processes. 

(Ref  8:  6  -  7) 

The  requirements  definition  for  this  project  occurred  during  a  long 
series  of  discussions  with  both  current  and  future  system  users.  From 
this,  a  comprehensive  understanding  of  the  operational,  functional,  and 
design  characteristics  evolved.  Taken  together,  these  three  characteris¬ 
tics  define  the  entire  system.  Separately,  they  define  why  the  system 
should  be  created,  what  the  system  should  be,  and  how  the  system  should 
be  constructed.  Figure  2  representatively  displays  this  process. 

This  and  the  preceding  chapter  incorporates  these  characteristics 
to  define  the  framework  for  the  remainder  of  this  paper.  Chapter  I 
identified  why  the  proposed  system  is  needed  by  defining  problems  inherent 
with  current  practice  and  the  author's  solution  to  those  problems.  It 
then  provided  a  basic  definition  of  what  the  system  should  be.  This 
characteristic  is  continued  in  this  chapter  through  identification  of 
principal  system  concepts  and  some  definition  of  how  they  interact  and 
are  used.  Finally,  primary  design  characteristics  and  considerations  for 
effective  man-machine  interaction  capabilities  are  discussed. 
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EXISTING 

CONDITIONS 


SYSTEM 

DESIGN 


Figure  2.  Requirements  Definition  Process  (Ref  8,  7) 

The  selection  of  an  interactive  computer  graphics  system  as  the 
most  viable  solution  to  the  problem  was  the  result  of  a  requirements 
analysis  as  described  above.  Existing  methodologies  required  that  the 
design  analyst  be  able  to  visually  correlate  as  much  defense  site  infor¬ 
mation  as  possible.  To  do  this,  he  used  a  series  of  large-area  maps, 
multi-colored  pins,  graphics  tape,  and  string  to  lay  out  and  define  the 
environment  scenario.  Once  the  scenario  was  satisfactorily  defined. 
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manual  measurement,  transcription,  and  keypunching  was  required  to  pre¬ 
pare  data  in  machine  readable  form  for  input  to  the  AADEM  model.  This 
long,  cumbersome  process  is  portrayed  in  Figure  3.  A  computerized  graphics 
system  seemed  to  be  the  most  obvious  and  simplistic  approach  in  upgrading 
such  a  tedious  and  potentially  unreliable  method.  The  graphics  terminal 
could  be  used  by  the  analyst  to  assign  or  modify  parameters  on  sites 
plotted  and  displayed  through  the  use  of  computer  graphics  techniques. 

This  proposed  process  is  pictorially  represented  in  Figure  4.  The  display 
would  provide  the  visual  correlation  capabilities  required  by  the  analyst 
while  the  computer  provided  efficient  data  management  and  validation 
processing. 

Many  AFAL  projects,  including  AADEM  simulations,  require  special 
handling  due  to  security  restrictions.  Because  of  this,  the  AFAL  is 
purchasing  a  PDP  VAX  11/780  Computer  System  to  which  a  TEKTRONIX  4016 
graphics  display  terminal  will  be  directly  linked.  The  composite  system 
will  be  located  in  a  secure  area  within  the  laboratory  thereby  permitting 
many  of  the  AFAL's  classified  projects  to  be  maintained  completely  in- 
house.  This  is  the  target  system  for  the  PDDS. 

Since  the  target  system  was  not  available  through  the  developmental 
portion  of  this  project,  development  of  the  PDDS  was  accomplished  on  the 
CYBER  175  Computer  System  at  the  ASD  Computer  Center.  All  programs  in 
the  PDDS  are  written  in  FORTRAN.  The  reasons  for  this  are  numerous: 

(1)  a  high-order-language  (HOL)  simplifies  portability;  (2)  FORTRAN 
is  the  only  HOL  on  the  target  system;  (3)  it  is  the  best  known  language 
among  end  users;  and  (4)  it  provides  the  simplest  interface  with  TEKTRONIX 
software  libraries. 


11 


INITIAL 

DATA 


> 


•  Plot  Defense  Elements 
on  World  Maps 

•  Associate  Command  and 
Control  Structure 

•  Collate  and  Transcribe 
Data 

•  Keypunch  P-Card  Data  Set 

5 


PCARD 

DATA 


Figure  3.  Manual  P-Card  Data  Definition  Process 


Early  in  the  requirements  definition  process,  it  became  apparent 
that  some  form  of  auxiliary  storage  data  base  would  be  required.  This 
determination  was  based  on  the  following  observations: 

(1)  The  system  includes  a  minimum  of  seven  site  types,  each 
characterized  by  a  unique  number  of  data  elements. 

(2)  Only  two  different  types  of  sites  require  concurrent  pro¬ 
cessing. 

(3)  Central  memory  restrictions  on  the  CYBER  175  limit  the  pro¬ 
cessing  *ize  of  interactive  programs. 

A  program  to  create  a  mass  storage  data  base  from  existing  site  identi¬ 
fication  data  files  was  defined.  A  random  access  file  structure  was 
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Figure  4.  PDDS  Process  Using  Interactive  Computer  Graphics 


chosen  for  the  data  base  as  it  provides  a  convenient  means  of  accessing 
selected  sections,  called  records,  on  the  file.  This  structure  also 
conveniently  addresses  all  observations  noted  above.  The  CYBER  175 
computer  system  library  contains  a  series  of  FORTRAN  callable  mass  storage 
input/output  (MSIO)  subroutines.  These  routines  were  used  to  create  and 
later  access  the  data  base.  A  comparable  set  of  I/O  routines  will  replace 
the  CYBER  MSIO  subroutines  when  the  PDDS  system  is  moved  to  the  VAX. 

AADEM  P-Card  data  basically  consists  of  two  types  -  site  dependent 
data  and  site  independent  data.  Site  dependent  data  constitutes  the 
physical  and  functional  attributes  of  each  site  whereas  site  independent 
data  is  either  constant  or  a  function  of  specific  site  dependent  data. 

Site  dependent  data  is  the  primary  target  of  the  PDDS  as  it  is  this  data 
that  is  most  tedious  and  time  consuming  to  define.  The  site  independent 
data  may  be  predefined  and  maintained  on  a  separate  file  rather  than  in 


the  data  base.  When  both  data  sets  are  complete  and  the  environment  has 
been  satisfactorily  defined,  data  from  each  file  is  merged  to  produce  the 
complete  P-Card  input  data  set. 

An  interactive  computer  graphics  program  was  determined  to  be  the 
tool  that  could  provide  the  most  efficient  interface  between  the  user/ 
analyst  and  the  data  base.  With  this  program,  the  analyst  could  effec¬ 
tively  display  and  modify  various  characteristics  within  the  environment 
and  immediately  observe  the  results  of  such  actions.  To  facilitate  dis¬ 
play  operations,  a  variety  of  user-initiated  options,  or  commands,  was 
identified  that  provides  all  required  display  manipulation  and  data 
definition  capabilities.  The  options  are  displayed  in  menu  format  for 
convenient  user  reference.  Each  is  named,  as  closely  as  possible,  in 
accordance  with  the  function  it  performs. 

The  TEKTRONIX  4016  restricts  user  interaction  to  either  textual 
input/output  through  use  of  the  terminal  keyboard  and  display  screen  or 
to  the  positioning  of  a  set  of  crosshairs  on  the  screen  surface.  While 
other  interactive  devices  such  as  a  lightpen  and  function  keys  would 
have  been  beneficial,  the  capabilities  provided  are  adequate  for  the 
PDDS.  Keyboard  input  was  chosen  for  primary  user/program  interaction  as 
this  method  tends  to  reduce  input  errors  by  causing  the  user  to  predefine 
his  desired  entry  and  "slowing  down"  his  response  actions.  The  crosshairs 
are  used  for  selecting,  or  picking,  sites  for  modification  or  parameter 
assignment,  and  for  identifying,  or  locating,  geographic  positions  for 
site  placement  within  the  display  area. 

The  basis  for  a  viable  interactive  program  is  that  the  program 
should  be  manipulated  by  the  user,  not  visa  versa.  (Ref  9:  31)  The 
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options  which  permit  the  user  to  modify  or  define  various  display  and 
data  parameters  fully  exploit  this  concept.  Through  selective  implementa¬ 
tion  of  these  options,  the  user  has  complete  control  of  program  flow. 

This  better  enables  him  to  complete  his  required  tasks  in  a  flexible, 
somewhat  carefree,  manner  with  an  increased  assurance  that  the  results 
will  be  as  anticipated. 

While  the  user  does  determine  what  actions  are  to  be  performed  by 
the  program,  the  program  must  often  obtain  certain  information  from  the 
user  before  it  can  accomplish  such  actions.  Thus,  a  conversational 
capability  must  be  incorporated  wherein  the  program  may  query  or  prompt 
the  user  when  such  information  is  needed.  This,  in  turn,  identifies  a 
requirement  for  a  comprehensive  error  checking  capability  within  the 
program  to  eliminate  the  possibility  of  program  failure  due  to  bad  or 
invalid  data.  For  this  process,  data  entered  through  the  terminal  key¬ 
board  is  best  received  by  the  program  in  alphanumeric  format  as  this 
format  permits  almost  all  keyboard  entry  combinations  (one  would  have  to 
deliberately  initiate  an  invalid  entry) .  Data  may  then  be  internally  vali¬ 
dated  and,  when  necessary,  decoded  into  the  appropriate  type  format. 
Additional  conversational  considerations  should  include: 

(1)  A  series  of  informative  and  diagnostic  messages  which  maintain 
user  awareness  of  program  activity. 

(2)  The  ability,  by  the  user,  to  void  any  inadvertent  or  errone¬ 
ously  initiated  action  through  the  use  of  a  unique,  coded,  keyboard 
entry. 
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(3)  A  process  whereby  the  user  may  obtain  some  guidance  from  the 
program,  on  request,  concerning  subsequent  actions  or  required 
inputs. 

(4)  A  shortened  input  form,  such  as  abbreviations,  for  routine 
or  often  used  entries. 

One  often  overlooked  aspect  during  the  requirements  definition 
process  is  that,  with  few  exceptions,  requirements  will  change.  Thus, 
during  this  process,  some  considerations  should  be  included  that  will 
facilitate  future  system  modifications  or  enhancements.  To  this  end,  the 
PDDS  is  structured  in  a  highly  modular  manner  to  better  enable  easy  file 
and  program  changes,  additions,  and  deletions.  The  modularity  concept 
also  applies  within  programs  and  is  particularly  applicable  to  the  PDDS 
interactive  graphics  program.  The  user-selectable  options  that  the  pro¬ 
gram  performs  logically  define  a  corresponding  individual  module  for 
each  function,  perhaps  comprised  of  several  routines,  but  complete  and 
independent  of  all  other  modules.  Primary  execution  then  loops  through 
a  central  control  point  and,  based  on  the  selected  function,  branches  to 
the  appropriate  module.  Future  module  additions  or  deletions  are  a 
simple  matter  of  adding  or  removing  branches. 


III.  SYSTEM  DEFINITION 


The  P-Card  Data  Definition  System  is  used  to  develop  and  assign  site 
dependent  data  during  preparation  of  the  ground-based  defense  environment 
input  data  for  an  AADEM  simulation.  Th  s  chapter  will  briefly  identify 
the  computer  systems  on  which,  and  for  which,  the  PDDS  was  developed  and 
all  support  software  used  ir.  the  development  and  implementat ' 'n  process. 

It  will  then  describe  the  organization  of  the  system,  identifying  each  of 
the  major  programs  and  files  concerned.  Next,  a  detailed  description  of 
the  purpose,  organization,  and  content  of  each  of  the  files  will  be  pro¬ 
vided.  Descriptions  of  the  major  programs  follow  in  Chapters  IV  and  V. 

Support  Hardware  and  Software 

As  mentioned  earlier,  the  AADEM  model  currently  executes  on  the  dual 
ITEL  AS-5  Computer  Systems  at  the  ASD  Computer  Center.  This  is  a  4 
megabyte,  32  bit/word  system  operating  under  MVS/JES2  and  is  principally 
used  for  large  information  data  processing  applications.  The  workload  on 
this  system  is  very  high,  and  often  incurs  immediate  priority  applications 
thus  generating  a  large  back-up  in  its  input  queue.  AADEM  simulation  runs 
own  a  very  low  priority  compared  to  normal  ITEL  applications.  In  addition, 
security  measures  often  dictate  special  handling  procedures  for  the  AADEM 
runs. 

Consequently,  the  AFAL  has  contracted  to  purchase  a  PDP  VAX  11/780. 
This  is  a  32  bit,  3  megabyte  virtual  memory  system.  The  system  will  be 
located  in  a  secure  area  at  the  laboratory  thereby  enabling  many  AFAL 
simulation  and  applied  analysis  programs  to  be  run  locally  rather  than  at 
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the  ASD  Computer  Center.  A  TEKTRONIX  4016  vector  graphics  display  termi¬ 
nal  will  be  wired  directly  to  the  VAX  to  provide  the  interactive  and 
graphics  capabilities  required  by  these  programs.  This  terminal  has  a  25 
inch  diagonal  display  screen  with  a  resolution  of  4096  x  4096  addressable 
points,  and  can  operate  at  transmission  speeds  up  to  9600  baud.  Both  the 
standard  TEKTRONIX  PLOT  10  and  the  Advanced  Graphing  II  software  libraries 
will  be  delivered  with  the  terminal.  The  VAX  11/780  with  the  TEKTRONIX 
4016  display  terminal  is  the  target  system  for  the  PDDS. 

The  PDDS  was  developed  using  CDC  INTERCOM  on  the  CYBER  175  system 
located  at  the  ASD  Computer  Center.  This  is  a  60  bit,  300K  word  system, 
operating  under  NOS/BE.  A  TEKTRONIX  4014  display  terminal  similar  to  the 
4016  was  used  in  the  development  process.  All  programs  were  written  in 
ANSII  standard  FORTRAN  IV  in  order  to  minimize  conversion  problems  between 
the  CYBER  and  VAX  systems.  Those  conversions  necessary  are  noted  in 
Appendix  A. 

An  integral  part  of  the  PDDS  is  a  data  base,  constructed  in  random 
file  format,  that  contains  all  site  data  used  to  define  the  environment. 

On  the  CYBER  system,  the  software  necessary  to  access  the  data  base 
consists  of  a  series  of  FORTRAN  callable  mass  storage  input/output  (MSIO) 
subroutines.  These  routines  are,  however,  totally  CYBER  dependent  (i.e., 
will  not  execute  on  any  other  system)  and  the  VAX  system  has  no  comparable 
capability.  Fortunately,  the  AFAL  has  a  series  of  routines  available 
that  will  perform  a  similar  function  on  an  IBM  370/155  series  computer 
system.  These  routines  will  be  modified  by  AFAL  personnel  to  provide 
access  to  mass  storage  on  the  VAX  in  a  manner  consistent  with  that  on  the 
CYBER  system. 
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System  Organization 


The  PDDS  consists  of  four  FORTRAN  IV  computer  programs  and  five 
principal  data  files  (three  input  and  two  output  files) .  The  system  is 
divided  into  three  distinct  components  which  correspond  to  the  three 
major  steps  in  the  total  system  process.  Each  of  the  components  is 
described  below  and  a  diagram  of  the  total  process  is  depicted  in 
Figure  5. 

The  first  system  component  consists  of  two  mass  storage  files 
(FILE-A  and  FILE-B)  and  the  first  of  the  primary  system  programs  (SETUP) . 
FILE-A  contains  the  basic  input  data  to  the  system.  This  file  is  already 
available  or  easily  obtained  from  source  tapes  since  personnel  at  the 
AFAL  use  the  data  on  it  for  several  applications  in  addition  to  AADEM 
simulations.  The  purpose  of  the  SETUP  program  is  to  create  the  system 
data  base,  designated  FILE-B,  through  a  conversion  and  definition  process 
based  on  the  type  and  amount  of  data  contained  in  FILE-A.  Because  of  the 
typical  memory  requirements  (>  60,000e  words)  and  the  minimum  amount  of 
user  interaction  necessary  for  this  step,  SETUP  is  executed  in  batch  mode 
on  the  development  system. 

The  second  component  also  consists  of  two  mass  storage  files  and  the 
second  system  program.  One  of  the  files  is  FILE-B,  the  output  file  from 
step  one  -  the  data  base.  It  is  FILE-B  with  which  the  user  interacts  via 
interactive  graphics  techniques  to  define  the  entire  AADEM  defense 
environment.  The  program  which  provides  the  interactive  interface  between 
the  user  and  the  data  base  is  called  UPDATE  as  it  does,  in  fact,  provide 
an  updating  capability. 


The  UPDATE  program  is  the  real  workhorse  of  the  entire  system.  With 
this  program,  the  user  may  add,  delete,  or  modify  sites  and/or  site- 
dependent  data  in  real  time  and  be  provided  with  immediate  visual  and 
narrative  feedback  on  the  effects  of  his  actions.  The  program  incorporates 
a  complete  data  validation  process  to  assure  that  all  changes  are  con¬ 
sistent  with  system  requirements  and  prior  user  actions.  Since  FILE-B 
is  a  permanently  stored  random  file,  all  changes  to  the  data  base  are 
permanent  changes  -  that  is,  they  remain  in  effect  when  normal  execution 
of  the  UPDATE  program  stops.  This  is  an  extremely  desirable  condition 
since  a  typical  environment  will  contain  from  700  to  800  sites,  each  of 
which  must  be  individually  and  fully  characterized.  This  process  will 
seldom,  if  ever,  be  completed  in  one  sitting. 

The  second  mass  storage  file  is  called  BACKUP  and  is  simply  a  second 
copy  of  the  most  recent  version  of  FILE-B.  On  the  development  system, 
this  file  is  maintained  under  a  separate  user  identification  number  on  a 
separate  disk  system  from  that  principally  used  by  the  PDDS.  The  intention 
of  this  procedure  is  to  minimize  the  possibility  of  losing  the  entire  data 
base,  and  probably  several  man-days  of  work,  if  some  system  malfunction 
should  destroy  the  disk  pack  containing  FILE-B.  BACKUP  is  recreated  each 
time  an  UPDATE  execution  terminates.  Similar  procedures  involving  a 
back-up  to  magnetic  tape  will  be  implemented  when  the  PDDS  is  moved  to  the 
VAX  system. 

The  final  system  component  consists  of  the  remaining  major  program 
and  three  mass  storage  files.  As  before,  one  of  the  files  is  FILE-B,  now 
the  completed  data  base.  The  purpose  of  this  step  is  the  preparation  of 
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the  P-Card  input  data  set  for  the  AADEM  model.  FILE-C  contains  site 
independent  data  -  i.e.,  data  that  is  fixed  relative  to  the  various  site 
dependent  attributes  assigned  through  UPDATE  and  contained  in  FILE-B. 

The  program,  called  APEND2,  retrieves  data  from  both  FILE-B  and  FILE-C 
and  merges  the  data  in  accordance  with  formats  prescribed  by  AADEM  to 
produce  each  specific  site  record.  APEND2  requires  no  user  interaction 
and  executes  in  batch  mode.  The  resultant  output  is  FILE-D,  the  P-Card 
data  set,  complete  and  properly  formatted  for  input  to  AADEM. 

Due  to  immediate  requirements  early  in  the  PDDS  implementation  pro¬ 
cess,  the  APEND2  program  was  provided  by  AFAL  personnel.  The  author  did, 
however,  provide  input  toward  development  of  the  program  and  has  included 
references  to  it  in  this  thesis  for  completeness. 

The  remaining  part  of  the  PDDS,  not  shown  in  Figure  5,  is  a  small 
utility  program  that  provides  an  annotated,  formatted  dump  of  the  data 
base  at  any  time.  The  program  executes  in  batch  mode  but  its  output  may 
be  routed  to  either  a  line  printer  or  an  on-line  interactive  terminal. 

File  Structure 

This  section  will  describe,  in  detail,  the  purpose,  structure  and 
content  of  each  of  the  system  files  with  the  exception  of  FILE-D,  the 
complete  P-Card  input  data  set.  The  FILE-D  format  is  adequately  covered 
in  the  AADEM  Input  Format  Guide  (Ref  13:  79)  and  need  not  be  repeated 
here. 

FILE-A:  This  file  contains  the  initial  data  set  to  the  PDDS  system 
and  is  the  basis  upon  which  the  total  system  environment  is  founded.  That 
is,  the  content  and  the  amount  of  data  (number  of  sites)  Identified  in 
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this  file  dictate  the  size  and  structure  of  FILE-B  from  which  the 
environment  is  characterized. 

FILE-A  consists  of  a  sequence  of  card-image,  ASCII  character  records, 
each  containing  seven  fields.  Figure  6  is  a  copy  of  a  part  of  the  file 
with  each  of  the  fields  as  indicated.  Explanation  of  each  field  follows: 

District  Number  -  This  is  an  identification  number  of  a  world 

geographic  area.  Typically,  this  area  is  the 
basis  for  each  AADEM  scenario,  however, 
neither  the  area  nor  its  representative 
number  have  any  importance  within  the  context 
of  the  PDDS. 

Site  Number  -  This  is  a  unique  identifier  of  each  site 

within  the  environment  and  is  the  primary  key 
in  the  overall  structure  of  the  system. 

X  &  Y  Coordinates  -  These  are  used  to  locate  the  site  within  the 

environment.  The  coordinates  are  assigned 
relative  to  some  externally  defined  fixed 
world  point  and  are  used  in  lieu  of  standard 
cartographic  reference  systems  for  simplicity 
and  security  purposes. 

Record  Type  -  Entries  in  this  field  distinguish  those 

records  which  identify  a  new  site,  represented 
by  an  "A",  from  those  records  which  assign 
various  types  of  radars  to  each  site,  repre¬ 
sented  by  a  "B". 
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00810b  31  -879*14.5025  C4-lt>7707u,7»  321b  3 ,*lC  A 

008  ICO  31  -879*14. ?C25  34-1577070. 7> 3210  701,' 1C  0 

0081C0  31  -879414.5225  14-157707 Q.7> 321L  3L4iA  B 
00810031  -879414.5  025  04-15778 7G«7»  321 C  3C7TA  B 
008 100  31  -879414 .5  025  '4-1577070 *7>  321C  3Q*TA  B 
308100  31  -87  9  41*.  5  0  2  5  04-15  77  0  7  0. 7  J321C  903!  A  B 

008  IOC  60  -544849. '-12227-1917075.  257  392  OGI  A 
00810160  -544849.412227-1917375.257392  303EW  B 

00810060  -5*48*9  .412227-1917375.257392  5C1HF  8 
u 08 IOC  60  -5*48*9.4 12227-1917075. 257  39  2  31?EW  B 

0  08  IOC  60  -5448*9 .*122  27-1917075.  25  7  392  3  3  EH  8 

00810060  -5448*9. .12227-1917075. 25733c  36SEW  B 
00810060  -5*48*9. .12227-1917075. 257332  3  C  3£W  B 

00810C60  -5448*9.412227-1917075.257392  3C1EM  B 
0C810C6C  -54*849  .4 122  27-1917075.  257392  512HF  B 

J0810C60  -544849.412227-1917075.257392  512HF  B 

00810060  -5448*9.412227-1917075.257392  3C4EM  B 
0 08 10b 67  -452.77.  228 16-1785459. 3i 0333  OEM  A 
0  08 luu  67  -452477.4228 16-1785459. 33T893  3.1EW  B 

00810067  -452*77.1.228  ’6-1785459.390893  5C3HF  B 
408  ICC 67  -452*77 .1  22816-1785459. 330893  9C5EH  e 
3  08 luC 67  -452*77..  22816-1785459. 33C393  30  +  EH  B 

*i  08  luc  67  -452477  .4223  16-l7o5459.  33  C  833  3.3EM  B 

008  lOL  67  -452*77  .-228  16-17  85459.  330353  3C1EW  B 
00810067  -452477.4228  16-1785459. 33C393  5C1HF  B 
0  08 IOC  67  -452*77 .-22816-1785*59.330333  303EH  B 

0 08 ICt 67  -452*77.4228  16-1785*55. 3JC333  512HF  B 

008 lOb  7  u  -9772** .555956-1347  896.3) 254;  3G1  A 

0  08 IOC 70  -977244. 6559*6-13*7896.3326.5  3C3EM  B 
u 08 IOC 7 0  -9772*4 .5  559  6-13*7596. 3| 26 ,5  3C1EW  B 
0  08  ICC 7  0  -9772*4 .6559 36-13*7896. 33 2b* 5  5'1HF  B 

00810070  -9772*4 .5 559  "6-1347  896. 3?  2545  5C2HF  B 
00810090-1027615. b 39 200-16034*7. 35C 32S  0  EH  A 

068100  90-1027615 .0  39200- 1603407. 3>  0323  5QIHF  B 
008 ICC  90-1027615.!  392  30-1603407*  35 C  323  5ulHF  B 
008 IOC 90-1027615 • C  39  2  3  0- 16  03*07 . 3>  0  32 E  305EH  B 


Figure  6.  FILE-A  Sample  Data 
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Coded  Radar  -  Contains  a  three  digit  code  which  identifies 

a  particular  radar  type  assigned  to  the 
incumbent  site. 

Site/Radar  Function  -  Two-character  entries  in  this  field  define 

the  site  function  if  on  an  "A"  record  and  the 
radar  function  if  on  a  "B"  record. 

FILE-B:  This  is  a  random-access  mass  storage  file  that  contains  the 
PDDS  system  data  base.  A  random  file  structure  was  chosen  for  FILE-B 
because  it  affords  an  easy  and  convenient  means  of  accessing  data  stored 
on  mass  storage,  thus  reducing  the  central  memory  requirements  of  all 
programs  that  access  this  file.  This  structure  also  permits  access  and 
retrieval  of  variable  length  records,  a  critical  requirement  of  the  PDDS. 
Alternate  storage  methods,  such  as  sequential,  could  not  provide  a  com¬ 
parably  efficient  interactive  capability. 

FILE-B  is  created  by  the  SETUP  program  using  data  obtained  from 
FILE-A.  It  consists  of  eight  variable  length  records,  where  the  length 
of  all  but  the  first  record  is  a  function  of  the  number  of  distinct  sites 
found  on  FILE-A.  Here,  the  term  variable  length  is  used  to  mean  that  no 
two  records  are  likely  to  be  the  same  length.  Once  the  data  base  has 
been  completely  defined  by  SETUP  the  length  of  each  record  remains 
constant. 

The  type  of  data  contained  in  each  of  the  eight  records  in  the  file 
is  as  follows: 

Record  1  -  System  definition  data  including  boundary  coordinates, 
site  counts,  and  status  Identification  flags. 
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Record  2  -  Basic  site  identification  data:  site  number, 
location,  and  function. 

Record  3  -  Early  Warning  site  data. 

Record  4  -  Group  Center  data. 

Record  5  -  Ground  Control  site  data. 

Record  6  -  Airfield  data. 

Record  7  -  Fire  Control  Center  data. 

Record  8  -  Surface-to-Air  Weapon  site  data. 

A  detailed  description  of  the  contents  and  structure  of  each  record  may 
be  found  in  Appendix  B. 

FILE-C:  This  file  contains  site  independent  data  that  is  merged 
with  the  data  on  FILE-B  to  create  the  complete  P-Card  data  set.  The  data 
on  this  file  is  either  constant  or  a  function  of  the  various  dependent 
parameters  associated  with  each  type  of  site  in  the  environment.  The  file 
structure  is  defined  in  accordance  with  requirements  of  the  APEND2  program 
and  data  assignments  are  made  by  AFAL  personnel. 

BACKUP:  As  previously  indicated,  this  file  is  an  exact  duplicate  of 
FILE-B,  and  maintained  only  for  file  security  purposes.  For  a  description 
of  this  file,  refer  to  the  FILE-B  description  above. 
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IV.  THE  SETUP  PROGRAM 


The  preliminary  design  analysis,  discussed  in  Chapter  II,  identified 
the  requirement  for  a  PDDS  system  data  base  that  would  provide  optimum 
storage  and  retrieval  capabilities  for  all  site  dependent  data.  It  further 
identified  a  random  access,  mass  storage  file  structure  as  the  most 
effective  implementation  of  such  a  data  base  as  this  structure  enables  a 
convenient,  functional  separation  of  data  consistent  with  system  require¬ 
ments.  This  chapter  discusses  the  structure,  operational  characteristics, 
and  limitations  of  the  program  used  to  create  the  PDDS  data  base  -  the 
SETUP  program. 

Structure 

The  SETUP  program  is  functionally  divided  into  two  basic  steps. 

During  the  first  step,  all  input  data  from  FILE-A  is  entered,  screened, 
and  sorted  into  various  holding  arrays  for  subsequent  processing.  The 
format  of  the  data  on  FILE-A  is  discussed,  in  detail,  in  Appendix  B. 

Data  is  entered  into  SETUP  in  record  format  where  a  record  is  one  line 
of  data  as  shown  in  Figure  6.  Each  record  contains  seven  data  elements 
used  to  characterize  an  associated  defense  site.  Some  data  may  be 
redundant  or  not  required  in  AADEM  simulations  and  is,  therefore,  not 
retained  for  PDDS  processing.  Only  data  pertinent  to  Early  Warning, 

Ground  Control  Intercept,  and  Surface-to-Air  Weapon  sites  is  retained. 

Once  all  the  data  has  been  entered  and  validated,  the  SETUP  program 
prepares  and  creates  the  eight  random-access  records  which  comprise  the 
PDDS  data  base.  This  process  includes  the  computation  of  some  system 
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accounting  data,  the  formation  of  records  containing  Group  Center  (GP) , 

Fire  Control  Center  (FC) ,  and  Airfield  (AF)  data,  and  some  data  manipula¬ 
tion  and  formatting  techniques  as  necessary  to  create  a  complete  and 
viable  system  data  base.  The  structure  of  the  file  containing  the  data 
base,  FILE-B,  is  described  in  Appendix  B.  As  each  mass  storage  record 
is  created,  a  copy  of  its  contents  is  written  to  the  system  output  file. 
Prior  to  program  termination,  a  listing  of  the  complete  data  base  is  then 
produced  for  user  information  and  verification. 

Operational  Characteristics 

During  step  one  in  the  SETUP  process,  each  site  is  uniquely  identified 
by  an  "A"  in  the  record  type  field  of  an  input  record.  Records  that  con¬ 
tain  a  "B"  in  this  field  identify  radar  units  assigned  at  each  site.  The 
function  field  of  each  "A"  record  is  used  to  identify  the  site  function: 

EW,  ET,  and  HF  denote  Early  Warning  sites,  GA  and  GI  identify  Ground  Con¬ 
trol  Intercept  sites,  and  MC  and  FC  identify  Surface-to-Air  Missile  sites. 
Sites  with  functions  different  from  those  noted  are  not  required  for  PDDS 
or  AADEM  purposes  and  are  ignored.  The  SETUP  program  tracks  these 
extraneous  site  types  with  a  count,  however,  and  includes  this  information 
in  the  listing  at  program  termination. 

A  site  count  of  retained  sites,  by  function,  is  accumulated  during 
the  input  process  and  is  used  as  a  basis  in  the  determination  of  all  mass 
storage  record  sizes.  Also,  the  maximum  and  minimum  X-Y  coordinates  are 
identified  during  this  process  and  subsequently  used  to  define  the 
boundaries  of  the  complete  AADEM  scenario.  Finally,  radar  units  located 
at  each  site  are  obtained  from  the  "B"  records  and  assigned  according  to 
the  following  rules: 
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EW  Sites  - 


a  maximum  of  four  search  (300  series)  and  three  height 
finder  (500  series)  radars  are  assigned.  Each  must  be 
unique.  If  "B"  records  do  not  identify  a  sufficient 
number  of  each,  remaining  assignments  are  zeroed. 

GC  Sites  -  one  search  and  one  height  finder  radar  is  assigned. 

Those  assigned  have  the  greatest  range  of  all  like 
radars  included  in  the  "B"  records  for  that  site. 

SA  Sites  -  one  tracking  (700  series) ,  one  acquisition  (300  and 
700  series),  and  one  height  finder  radar  is  assigned. 
Additionally,  the  weapon  type  at  each  site  is  determined 
by  the  type  of  tracking  radar  located  there.  Weapon 
type  and  radar  assignments  for  these  sites  are  as 
defined  in  Table  II. 

Before  the  data  base  can  be  properly  defined,  some  general  system 
accounting  data  must  be  determined.  The  initial  number  of  active  sites 
of  each  type  which  were  compiled  from  FILE-A  during  the  first  step  of  the 
SETUP  process  are  used  to  compute  the  maximum  number  of  each  type  of  site 
that  the  data  base  will  support.  These  values  will  vary  between  different 
AADEM  scenarios,  but  once  they  are  determined  for  a  particular  scenario 
they  remain  fixed.  Distinct  AADEM  scenarios  are  determined  by  AFAL  pro¬ 
gram  requirements  and  are  defined  for  the  PDDS  by  the  unique  site  informa¬ 
tion  contained  on  each  FILE-A.  Thus,  SETUP  defines  two  counters  that  are 
used  to  track  each  functionally  unique  site.  One  contains  the  maximum 
number  of  each  site  type  permitted  in  the  data  base  and  remains  constant. 
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TABLE  II 


SA  Weapon  Type  and  Radar  Assignment  Configuration 


Weapon 

Type 

Identify 

By 

Radar  Assignment 

Tracking 

Acquisition 

Height  Finder 

1 

708 

708 

708 

0 

2 

703 

703 

703 

0 

3 

702 

702 

702 

0 

4 

701 

701 

304 

512 

5 

705 

705 

307 

512 

6 

706 

706 

308 

512 

7 

707 

707 

308 

512 

8 

704 

704 

714 

512 

9 

712 

712 

309 

512 

The  other  is  used  by  the  UPDATE  program  to  keep  track  of  the  number  of 
sites,  by  type,  that  are  active  at  any  particular  time  and  changes  with 
the  occurrance  of  various  site  additions  and  deletions. 

Table  III  identifies  the  computations  used  to  calculate  the  maximum 
number  of  sites,  by  type,  permitted  in  the  data  base  based  on  the  initial 
number  of  sites  in  FILE-A.  A  20%  increase  in  the  number  of  EW,  GC,  and 
SA  sites  is  permitted.  The  maximum  GP,  FC,  and  TA  sites  is  then  computed 
from  the  maximum  EW  and  SA  site  counts.  Airfields  must  equal  the  number 
of  GC  sites.  A  maximum  of  two  headquarters  (one  primary,  one  alternate) 
is  permitted  in  each  scenario.  These  limits  are  based  on  the  current 
command  and  control  configuration  of  the  AADEM  model  wherein  five-to-one 
EW-GP,  SA-FC,  and  SA-TA  site  ratios  are  maintained.  A  one-to-one  GC-AF 
ratio  is  required. 
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TABLE  III 


Site  Count  Computations 


Site 

Type 

Initial 
Number  of 
Active  Sites 

Maximum 
Number  of 
Sites 

Number  of 
Data  Elements 
Per  Site 

Early  Warning  (EW) 

i 

1=  1.2i 

19 

Group  Center  (GP) 

0 

0.2  I 

1 

Headquarters  (HQ) 

0 

2 

— 

Ground  Control 
Intercept  (GC) 

j 

J=  1.2j 

6 

Airfield  (AF) 

0 

J 

3 

Fire  Control 

Center  (FC) 

0 

0.2  K 

7 

Surface-to-Air 

Weapon  (SA) 

k 

K  =  1 . 2k 

6 

Tactical  (TA) 

0 

0.2  K 

8 

Each  site  type,  except  Headquarters,  identifies  a  separate  mass 
storage  record.  The  record  formats  and  the  data  elements  stored  in  each 
record  are  defined  in  Appendix  B.  For  convenience,  the  number  of  data 
elements,  per  site,  within  each  record  is  repeated  in  Table  III.  This 
number,  when  multiplied  by  its  associated  maximum  site  count,  defines 
the  word  length  of  each  mass  storage  site  record.  The  word  length  is  ini¬ 
tially  required  to  write  each  record  to  mass  storage  and  then  later  required 
by  all  PDDS  component  programs  when  access  to  the  data  base  is  necessary. 

The  scenario  geographic  boundaries  were  determined  by  tracking  the 
maximum  and  minimum  X/Y  site  coordinates  during  the  initial  SETUP  process. 

In  step  two,  the  final  boundaries  are  enlarged  by  1%  in  each  direction 
(xmax,  xmin,  ymax,  ymin)  to  enable  scenario  expansion. 


The  final  task  of  the  SETUP  program  is  to  prepare  each  record  and 
write  it  to  mass  storage.  As  most  records  contain  both  integer  and 
floating  point  data  fields  in  varying  positions,  FORTRAN  equivalencing 
techniques  are  used  in  this  process.  The  mass  storage  input/output  (MSIO) 
routines  require  that  all  data  transfer  takes  place  through  one  large 
array.  Two  equivalenced  array  names  are  specified  for  this  array.  One  is 
type  real  (REC)  and  the  other  type  integer  (IREC) .  This  permits  both  data 
types  to  be  assigned  to  the  same  central  memory  locations  but  removes  the 
problem  of  implicit  type  conversions  during  the  assignment.  Floating  point 
data  elements  may  be  assigned  to  storage  locations  in  REC  and  integer  values 
to  locations  in  IREC.  Using  this  methodology,  then,  SETUP  prepares  each 
record  in  accordance  with  formats  defined  in  Appendix  B  and  writes  (trans¬ 
fers)  the  record  to  mass  storage,  thus  creating  the  PDDS  data  base  - 
FILE-B. 

Limitations 

The  SETUP  program  is  restrictive  in  the  number  and  types  of  sites  it 
will  retain  from  FILE-A  for  inclusion  in  the  PDDS  data  base  and  in  the 
types  of  radars  it  can  include  in  each  site  record.  Furthermore,  it  fixes 
the  size  of  each  data  base  it  develops  from  FILE-A  for  a  given  AADEM 
scenario.  These  limitations  are  purposely  incorporated  into  the  program 
design,  primarily  for  convenience  rather  than  necessity.  Central  memory 
limitations  in  interactive  mode  on  the  development  system  dictate  that 
either  the  size  of  the  data  base  remain  fairly  small  or  that  complex 
dynamic  storage  and  retrieval  techniques  be  used.  Since  the  target  system 
is  a  virtual  memory  system  with  minimal  central  memory  limitations. 
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straightforward  accessing  methods  are  used  in  the  system  at  the  expense 
of  larger  central  memory  requirements.  When  the  PDDS  is  converted  to  the 
target  system,  array  dimensions  may  be  easily  enlarged  and  tests  for 
additional  site  and  radar  types  included  to  enable  a  fully  operational 
data  base. 
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V.  THE  UPDATE  PROGRAM 


Previous  chapters  have  discussed  why  the  P-Card  Data  Definition 
System  is  required,  some  considerations  used  in  its  design,  the  resultant 
system  components  that  evolved  from  that  design,  and  how  one  of  these 
components,  the  data  base,  is  created.  The  hub  of  the  entire  PDDS  is  an 
interactive  graphics  program,  called  UPDATE,  around  which  all  other  sys¬ 
tem  components  are  defined.  This  chapter  will  describe  the  UPDATE  pro¬ 
gram,  its  structure,  its  interface  methodology,  and  some  of  the  operational 
characteristics  which  make  UPDATE  an  efficient,  effective,  and  error-free 
processing  tool. 

Program  Description 

The  UPDATE  program  is  used  to  define  and  modify  parameters  that 
characterize  defense  elements  within  an  AADEM  scenario.  All  operations 
performed  by  the  program  occur  in  response  to  a  series  of  user  initiated 
commands,  called  options,  that  are  entered  through  the  terminal  keyboard. 
Two  types  of  options  are  included  in  the  program:  data  definition  options 
through  which  site  dependent  parameters  may  be  assigned,  deleted,  or 
corrected  and  utility  options  which  enable  display  manipulation  and  pro¬ 
vide  textual  information  to  the  user.  If  information  other  than  the  option 
name  is  required,  additional  prompts  or  questions  are  issued  by  the  program 
to  which  the  user  must  respond  accordingly.  All  user  inputs  are  validated 
before  processing  continues. 

Figure  7  defines  the  format  of  the  UPDATE  graphics  display  surface. 

The  screen  is  functionally  divided  into  three  areas:  the  I/O  area,  the 
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I/O 

AREA 


Figure  7.  Display  Surface  Format 

Menu  area,  and  the  Display  area.  All  narrative,  or  textual,  communica¬ 
tions  between  the  program  and  the  user  occur  in  the  I/O  area;  the  Menu 
area  contains  a  list  of  all  user-selectable  options;  and  the  Display 
area  is  the  window  in  which  all  graphics  output  is  displayed. 

Sixteen  options  have  been  identified  which  provide  maximum  program 
utility.  The  option  names  are  listed  in  the  Menu  area  during  all  dis¬ 
plays  for  convenient  reference  as  follows: 


ADD 

CHANGE 

CIRCLE 

DELETE 

DISPLAY 

HELP 

LINK 

LOCATE 

MOVE-SITE 

PICK-ID 

REDRAW 

RESET 

RETURN 

SCALE 

STOP 

ZOOM 

The  option  names  are  representative  of  the  actions  they  perform.  The 
PDDS  System  User’s  Guide,  Appendix  E,  describes,  in  detail,  the  purpose 
and  operation  of  each. 
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TABLE  IV 


PDDS  Site 

Pairs 

tariy  warning  " 

t^roup  centers 

Ground  Control  Intercept  ♦ 

Surface-to-Air  Weapons 

Airfields 

Strategic  4 

♦  Fire  Control  Centers 

Tactical  4 

♦  Tactical  Support  Centers 

The  display  generated  by  the  UPDATE  program  depicts  the  locations 
of  the  various  defense  elements  (sites)  within  the  current  AADEM 
environment.  Each  site  type  is  represented  by  a  unique  symbol  (Table  E-I) . 
Three  types  of  displays  may  be  output:  a  plot  of  all  sites  in  the 
environment,  a  plot  of  all  sites  of  a  particular  type,  or  a  plot  of  all 
sites  within  a  site  pair.  A  site  pair  is  a  set  of  two  sites  tied  together 
within  the  AADEM  hierarchy  for  command  and  control  purposes.  Site  pairs 
are  indicated  in  Table  IV  and  follow  the  structure  of  Figure  1. 

The  user  defines  the  type  of  display  required  through  specification 
of  the  DISPLAY  option.  If  all  sites  are  plotted,  some  restrictions  on 
subsequent  user  actions  are  imposed  because  of  the  potentially  complex 
and  congested  display  and  because  of  limited  data  base  accessing  capabili¬ 
ties  while  in  this  mode.  A  diagnostic  message  is  displayed  if  initiation 
of  any  restricted  actions  is  attempted.  When  displaying  unique  sites  or 
site  pairs,  alJ  possible  actions  are  enabled. 

Surface-to-air  weapon  (SA)  sites  demand  special  attention  within  the 
PDDS.  There  are  nine  types  of  surface-to-air  weapon  systems  identified 
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for  inclusion  in  the  AADEM  model  -  three  anti-aircraft  (AAA)  and  six 
missile  (SAM)  systems.  When  displaying  SA  sites,  the  user  may  further 
define  which  weapon  system(s)  he  requires  through  numerical  identifica¬ 
tion  of  the  particular  systems.  Weapon  types  1,  2,  and  3  identify  AAA 
sites  while  types  4  through  9  identify  SAM  sites.  SAM  systems  are  further 
subdivided  as  Strategic  (types  4,  5,  9)  and  Tactical  (types  6,  7,  8).  The 
user  may  then  display  all  SA  sites,  a  unique  weapon  type,  or  any  combina¬ 
tional  configuration  of  weapon  types. 

Structure 

The  basic  functional  structure  of  the  UPDATE  program  is  indicated  in 
Figure  8.  Appendix  F  provides  a  more  detailed  set  of  diagrams  which 
depict  the  primary  configuration  of  the  program.  UPDATE  consists  of  three 
major  segments:  the  initiation  segment  (STARTUP),  the  execution  segment 
(OPTION) ,  and  the  termination  segment  (ENDUP) .  STARTUP  and  ENDUP  both 
provide  basic  housekeeping  functions  necessary  to  ensure  viable  program 
(and  system)  operation.  STARTUP  opens  the  mass  storage  file,  initializes 
the  graphics  and  program  common  areas,  informs  the  user  of  current  system 
status,  and  enables  the  initial  display  of  site  data  as  specified  by  the 
user.  ENDUP  clears  all  common  areas  and  program  buffers,  ensures  that  all 
site  records  are  properly  sorted  and  written  to  mass  storage,  and  closes 
the  mass  storage  file. 

All  data  and  display  manipulation  activities  are  initiated  by  the 
user  in  the  OPTION  segment.  Program  flow  is  controlled  by  the  OPTION 
subroutine  for  it  is  through  this  routine  that  the  user  enters  the  par¬ 
ticular  option  he  wishes  to  invoke.  When  an  option  is  entered,  control 
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Figure  8.  UPDATE  Functional  Structure 


branches  to  the  routine,  or  set  of  routines,  that  will  perform  the  required 
actions.  Once  all  actions  are  completed,  control  returns  to  the  OPTION 
subroutine  and  the  process  is  repeated.  Figure  9  portrays  this  process 
schematically. 

Interface  Methodology 

The  UPDATE  program  is  the  medium,  or  interface,  that  permits  the  ideas 
and  data  values  known  by  the  user/analyst  to  be  transmitted  and  stored 
accurately  and  efficiently  in  the  PDDS  data  base.  To  meet  this  requirement, 
the  program  incorporates  a  detailed  conversational  and  error  checking 
capability  that  maintains  continual  user  awareness  of  program  status  and 
needs  and  provides  a  mechanism  for  effective  communication  between  the  user 
and  the  program. 

All  user  inputs  are  performed  through  some  form  of  terminal  keyboard 
entry  in  response  to  a  prompt  or  query  from  the  program.  For  each  prompt 
or  query  that  is  issued,  a  fixed  set  of  valid  user  responses  is  known  and 
anticipated  by  the  program.  The  program  immediately  compares  each  entry 
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Figure  9.  The  OPTION  Control  Loop 

with  the  set  of  valid  responses.  Valid  entries  continue  program  execution; 
invalid  entries  cause  an  error  message  and  a  repeat  of  the  original  prompt 
or  query. 

Formatted  alphanumeric  FORTRAN  read  statements  are  used  as  the  input 
medium  for  all  user  entries.  Thus,  any  standard  keyboard  entry  may  be  made 
without  causing  run-time  I/O  errors  and  possibly  terminating  execution 
prematurely.  Valid  numeric  data  entered  in  this  manner  is  decoded  into  its 
appropriate  type  prior  to  program  continuation. 
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All  textual  output  from  the  program  is  accomplished  through  use  of  a 
TEKTRONIX  subroutine,  AOUTST.  There  are  two  reasons  for  this:  (1)  AOUTST 
forces  all  textual  output  to  take  place  through  the  TEKTRONIX  output  buffer. 
As  this  data  would  be  placed  in  the  buffer  after  any  prior  graphics  data, 
it  provides  the  assurance  that  all  data,  graphic  and  textual,  will  be  dis¬ 
played  since  the  entire  buffer  must  be  cleared  in  order  to  display  the 
textual  data.  FORTRAN  output  routines,  alone,  cannot  provide  this  assur¬ 
ance;  (2)  this  method  maintains  control  of  the  terminal  graphic  status 
thus  removing  the  requirement  for  additional  resetting  procedures  after 
each  output. 

The  program  will  provide  narrative  help  to  the  user,  on  request,  in 
two  forms.  The  first  is  through  initiation  of  the  HELP  option.  This  will 
provide  a  most  general  form  of  help  by  displaying  a  definitive  list  of  all 
user-selectable  options  and  a  site  symbol/abbreviation  table  in  compact, 
reproducible  form.  A  more  specific  form  of  help  is  provided  if  the  word 
"HELP"  is  entered  when  the  program  anticipates  a  particular  data  entry. 

In  this  case,  the  program  will  identify  that  entry,  or  group  of  entries 
it  deems  valid.  Entries  of  an  indefinite  nature,  such  as  site  number  or 
location,  are  narratively  identified. 

All  entries  other  than  numeric  data  entries  may  usually  be  abbreviated. 
This  is  particularly  true  when  initiating  any  of  the  sixteen  user-selectable 
options.  While  the  complete  name  may  be  entered,  only  the  first  three 
characters  are  validated  within  the  program.  Yes  or  No  responses  are 
required  at  various  times  throughout  program  execution.  Here  a  Y  or  an  N 
will  suffice;  as  before,  however,  the  entire  word  may  be  entered.  Site 
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type  identification  may  only  be  performed  by  abbreviation.  Each  site 
abbreviation  is  listed  in  Table  E-I  of  the  user's  guide. 

The  program  is  designed,  therefore,  to  minimize  user  interface 
problems  and  maximize  data  integrity  through  a  series  of  diagnostic 
messages  and  validation  procedures.  The  program,  as  all  PDDS  components, 
is  structured  so  that  no  internal  or  user-initiated  action  will  cause 
inadvertent  program  termination  or  file  destruction. 

Operational  Characteristics 

The  UPDATE  program  consists  of  a  main  program  and  39  subroutines. 

The  main  program  consists  entirely  of  three  subroutine  calls:  one  each 
to  STARTUP,  OPTION,  and  ENDUP.  Fifteen  of  the  subroutines  are  named  in 
correspondence  with  user-selectable  option  names  (STOP  returns  control  to 
the  main  program)  and  it  is  within  these  that  execution  of  the  specified 
option  begins.  With  few  exceptions,  however,  these  routines  do  little 
more  than  estab'ish  parameters  and  make  appropriate  calls  to  a  series  of 
lower-level  routines  where  the  bulk  of  the  work  of  the  program  is 
accomplished. 

Because  a  variety  of  data  must  be  available  to  most  routines  at  all 
times,  two  common  areas  are  used:  a  named  common,  GRAFIX,  which  contains 
all  program  data  such  as  flags,  counters,  and  constant  data  peculiar  to 
each  scenario,  and  a  blank  common  area  which  is  used  to  store  all  site 
data  while  it  is  in  memory.  The  contents  and  purpose  of  all  elements  in 
each  of  the  common  areas  are  described  in  Appendix  G.  Equivalencing 
techniques  as  described  in  Chapter  IV  are  used  to  assign  or  access  data 
elements  in  each  area. 
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The  key  to  many  of  the  operations  performed  by  the  UPDATE  program 
is  that  the  master  record  (mass  storage  record  it 2)  and  all  site  records 
are  ordered  by  site  number.  This  is  especially  true  when  sites  are  being 
displayed,  but  it  is  also  necessary  when  searching  for  a  particular  site 
within  each  record. 

As  described  in  Appendix  B,  the  master  record  contains  the  site 
number,  location  coordinates,  and  function  of  all  sites  in  the  current 
scenario.  This  data  is  entered  into  corresponding  arrays  in  blank  common 
during  STARTUP  and  remains  in  memory  until  program  termination.  To  plot 
all  sites,  subroutine  PLOTALL  sequentially  scans  the  coordinate  arrays  and 
draws  each  site  symbol  according  to  function.  Individual  site  records  are 
stored  in  memory  in  the  large  mass  storage  array  REC.  To  plot  only  these 
sites,  subroutine  S1TEPLT  sequentially  obtains  a  site  number  from  REC, 
locates  a  match  in  the  master  record  and  thus  has  the  site  coordinates  for 
plotting.  Since  both  records  are  ordered  by  site  number,  successive 
searches  in  the  master  record  for  each  new  site  need  not  start  at  the 
beginning  but  may  continue  from  the  point  where  the  previous  site  was 
located. 

Several  processes  within  UPDATE  require  knowledge  of  a  site  number 
array  subscript  in  order  to  directly  access  corresponding  arrays.  Since 
the  arrays  are  ordered  on  site  number,  an  efficient  binary  search  (sub¬ 
routine  BISECT)  is  used  to  obtain  the  required  index.  However,  it  is 
often  necessary  to  obtain  the  site  number  based  on  its  location  before  the 
specified  action  can  be  accomplished.  Since  the  coordinate  arrays  are  not 
ordered,  a  less  efficient  sequential  search  for  a  site  whose  assigned 
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coordinates  are  within  some  epsilon  distance  from  the  input  location  must 
be  used.  The  input  location  is  determined  by  the  intersection  of  the 
terminal  crosshairs  set  by  the  user  within  the  display  area.  Subroutine 
PICK  performs  this  function  using  one-half  the  current  symbol  height  to 
define  the  "hit"  area. 

A  temporary  storage  buffer  is  used  in  the  UPDATE  program  in  con¬ 
junction  with  the  ADD  option.  This  option  permits  the  user  to  add  sites 
of  any  type  at  all  times  during  program  execution.  The  function  of  the 
added  site  may  be  different  from  the  type  of  sites  currently  being  dis¬ 
played.  Therefore,  since  all  site  records  are  not  in  memory  concurrently, 
a  New-Site  buffer  is  used  to  store  the  site  number  and  function  of  each 
added  site.  Both  site  plotting  routines  check  this  buffer  prior  to  com¬ 
pletion.  In  addition,  the  DELETE  routine  checks  this  buffer  if  a  site 
specified  for  deletion  cannot  be  found  in  the  current  memory-resident 
site  record(s).  Newly  added  sites  stored  in  the  New-Site  buffer  are 
sorted  into  their  respective  site  records  through  initiation  of  the  RESET 
option. 

With  site  additions  and  deletions  possible  at  any  time,  maintaining 
the  currency  of  the  master  record  and  various  site  records  becomes  a  major 
problem.  Prior  to  entering  a  new  site  record  or  site  record  pair  into 
memory,  all  data  from  the  current  site  record(s)  must  be  returned  to  mass 
storage.  Before  this  may  occur,  the  site  record(s)  must  be  updated  with 
respect  to  newly  added  or  deleted  sites  and  sorted  accordingly.  Also  at 
this  time,  those  sites  added  to  the  record (s)  are  removed  from  the  New-Site 
buffer  and  the  master  record  is  updated  and  sorted.  The  current  records 
are  then  written  to  mass  storage  and  the  new  records  entered  into  memory. 
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The  sorting  algorithm  used  is  a  shell  sort  (Ref  5,  134)  ,  modified 
to  enable  the  sorting  of  the  variable  length  records  maintained  in  the 
PDDS  data  base.  This  algorithm  is  used  because  it  is  identified  by 
Wirth  (Ref  12,  84-87)  as  a  highly  efficient  multi-field  sorting  method 
and  because,  among  different  but  comparably  efficient  algorithms,  it 
seemed  the  most  adaptable  to  FORTRAN  implementation. 

Subroutine  STARTUP  enters  all  data  from  mass  storage  records  1  and  2 
into  memory  and  assigns  it  to  the  appropriate  storage  location  in  the 
GRAFIX  and  blank  common  areas.  Subroutine  ENDUP  reverses  this  process 
after  ensuring  that  both  program  buffers  have  been  cleared  and  all  site 
records  properly  updated.  All  data  base  input/output  within  the  OPTION 
segment  is  taken  care  of  by  subroutine  DBIO.  Using  two  GRAFIX  common 
variables,  KTYP  and  LTYP,  DBIO  identifies  the  correct  record  to  be  trans¬ 
ferred,  computes  all  necessary  transfer  parameters,  and  initiates  the 
transfer. 

A  brief  description  of  the  usage  of  all  routines  in  the  UPDATE  pro¬ 
gram  is  included  as  Appendix  D  of  this  paper.  The  program  is  highly 
modularized,  with  all  routines  performing  a  unique  function.  With  the 
exception  of  the  main  program,  named  UPDATE,  all  routines  are  contained 
in  alphabetical  order,  by  name,  within  the  program  as  an  aid  to  locating 
each  one,  as  necessary. 


44 


VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


The  primary  objective  of  this  thesis  was  to  design  and  implement  a 
viable  data  definition  and  validation  system  that  would  maximize  the 
integrity  of  the  input  data  to  the  AADEM  simulation  model  through  the 
use  of  interactive  computer  graphics.  An  additional  objective  was  to 
produce  and  deliver  a  useable  product  which  incorporated  an  effective 
man-machine  communications  capability  consistent  with  contemporary  human 
engineering  concepts  and  practice.  This  chapter  briefly  summarizes  the 
results  of  the  PDDS  development  effort  and  proposes  some  ideas  and 
recommendations  for  future  system  modification  and  enhancement. 

Conclusions 

Both  of  the  above  objectives  were  realized.  The  P-Card  Data  Defini¬ 
tion  System  provides  AFAL  personnel  with  an  almost  totally  automated 
process  for  defining  and  preparing  P-Card  data  for  input  to  AADEM.  FILE-C, 
a  comparatively  small  file  containing  site  independent  data,  is  the  only 
exception  since  this  file  must  still  be  prepared  manually. 

The  SETUP  program  constructs  the  system  data  base  from  initial  site 
characterization  data  provided  on  FILE-A.  The  data  base  is  a  random 
access,  mass  storage  file  that  contains  site  dependent  data  for  all 
identified  defensive  elements  in  the  scenario.  The  UPDATE  program  is  an 
interface  between  the  analyst  and  the  data  base  and  provides  an  effective, 
easy-to-use  mechanism  through  which  the  analyst  may  assign,  delete,  or 
otherwise  modify  all  site  dependent  data  values  in  the  data  base.  The 
graphics  display  and  option  selection  capabilities  provided  by  the  UPDATE 
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program  enable  the  analyst  to  perform  all  required  data  manipulation 
procedures  easier,  faster,  and  with  a  greater  degree  of  confidence  in 
the  validity  of  the  results  than  with  the  previously  used  manual  methods. 
A  complete,  properly  formatted  P-Card  data  set  may  then  be  produced  by 
merging  the  dependent  and  independent  data  through  execution  of  the 
APEND2  program. 

One  major  deficiency  in  the  total  PDDS  process  exists.  For  purposes 
of  this  project,  a  total  system  design  and  component  definition  was 
completed,  however,  only  those  aspects  of  the  system  relevant  to 
strategic  defense  elements  have  been  implemented.  The  capability  to 
define  and  modify  tactical  site  data  has  not  been  included.  This  exclu¬ 
sion  occurred  because  of  a  revision  in  system  requirements  and  subsequent 
schedule  slippage  midway  through  the  development  effort.  Completion  of 
all  functional  characteristics  of  the  system  was  then  determined  to  have 
highest  priority  with  the  incorporation  of  tactical  site  data  only  if 
time  permitted.  Unfortunately,  time  ran  out  before  the  tactical  data 
definition  capability  could  be  included. 

A  recommended  approach  for  the  inclusion  of  tactical  site  data  in 
the  PDDS  and  other  system  enhancements  follows. 

Recommendations 

Inclusion  of  the  capability  for  storing,  defining,  and  modifying 
tactical  site  data  should  be  completed  at  the  earliest  possible  time. 
Listed  below  are  procedures  and  other  information  the  author  deems 
necessary  to  accomplish  this: 

(1)  An  additional  mass  storage  record  in  the  PDDS  data  base  will 


be  necessary  to  store  all  site  related  data. 


a)  Data  for  all  four  TA  site  functions  may  be  retained  on  this 
record  with  individual  sites  hierarchically  linked  by  site 
number . 

b)  The  record  must  be  created  by  SETUP.  Suggest  a  maximum 
site  count  of  20%  of  the  total  number  of  SA  sites  identified 
by  SETUP. 

(2)  Because  of  site-type  code  implementation  in  the  PDDS,  the  new 
record  might  best  be  inserted  as  mass  storage  record  number  eight; 
redesignating  the  current  eighth  record  as  number  nine. 

a)  Common  area  variables  then  needing  modification  are:  NAS, 
NTS,  NWORDS ,  NSINC,  and  KODE. 

b)  Other  variables  requiring  modification  in  the  UPDATE  pro¬ 
gram  are  SITETYP  and  NFLDS.  These  variables  are  found  in 
several  routines  under  the  same  name  and  perform  like  functions 
in  each.  Perhaps  they  could  be  added  to  GRAFIX  common. 

(3)  The  codes  (KODE)  used  to  define  the  TA  sites  will  immediately 
impact  the  following  routines,  each  in  a  similar  manner:  ADD, 
CHANGE,  DBIO,  DELETE,  DISPLAY,  LINK,  MOVSITE,  PICK,  PLOTALL,  RESECT, 
and  SITEPLT. 

(4)  A  flag  should  be  incorporated  in  the  UPDATE  program  and  used  to 
designate  the  display  of  either  tactical  or  strategic  SAM  sites, 
when  appropriate.  It  would  then  be  used  to  identify  which  companion 
site  type  (TA  or  FC)  should  also  be  displayed. 
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(5)  The  FORTRAN  source  code  to  draw  TA  site  symbols  has  been 
incorporated  in  the  SYMBL  subroutine. 

One  additional  recommendation  is  relevant.  In  moving  from  the 
current,  manual  site  definition  methods  to  the  PDDS,  the  user /analyst 
must  give  up  a  significant  visual  correlation  capability  since  he  no 
longer  has  direct  use  of  large  area  maps  with  their  associated  terrain 
feature  representations.  Several  procedures  that  may  provide  some 
help  in  this  regard  follow: 

(1)  Include,  in  the  PDDS,  a  graphical  terrain  drawing  capability. 

This  could,  however,  be  a  most  difficult  and  costly  process  as 
worldwide  terrain  characteristics  (some  in  minute  detail)  would  be 
required. 

(2)  Obtain  transparent  overlays  that  depict  terrain  characteristics 
at  select  (probably  level  0)  displays.  This,  too,  could  be  a  costly 
and  cumbersome  process. 

(3)  Post  a  large  area  map  near  the  display  terminal  with  an  outline 
around  the  basic  scenario  area.  The  analyst  may  then  reference  this 
map  and  obtain  approximate  associative  terrain  and  site  relationships. 

None  of  the  above  recommendations  for  visual  correlation  of  terrain 
characteristics  is  very  beneficial  from  either  an  economical  or  a  user 
standpoint.  When  the  system  begins  to  be  used  on  a  regular  basis,  however, 
it  is  almost  a  certainty  that  the  analyst  will  devise  his  own  methods  to 
overcome  this  deficiency. 
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APPENDIX  A 


CDC/VAX  CONVERSION  REQUIREMENTS 


APPENDIX  A 


CPC /VAX  CONVERSION  REQUIREMENTS 


All  PDDS  system  programs  are  written  in  ANSI  Standard  FORTRAN  IV. 

One  of  the  reasons  for  this  is  to  minimize  problems  when  the  system  is 
moved  from  the  development  system  (CYBER  74/175)  to  the  target  system 
(VAX  11/780).  However,  while  both  systems  support  the  designated  language, 
differences  within  their  compilers  do  exist. 

Table  A-I  lists  all  known  significant  (i.e.,  likely  to  produce  fatal 
compilation  or  execution  errors)  differences  through  identification  of  the 
correct  syntax  for  each  system  and  identification  of  the  routines  where 
corresponding  changes  must  be  made.  All  required  changes  have  been 
incorporated  into  the  UPDATE  program  as  commented,  full-line  replacements 
immediately  following  the  line  to  be  replaced.  Each  replacement  line  is 
easily  identified  since  the  characters  "C-VAX"  are  the  first  characters  in 


each  line. 


TABLE  A- I 


CDC/VAX  Conversion  Requirements 


PROBLEM 

CDC  SYNTAX 

VAX  SYNTAX 

PROGRAM  UNIT 

Intrinsic  Function 

AND 

LAND 

Many.  External  IOR 

Names 

OR 

IOR 

and  IAND  functions 
included  in  program. 
Remove  when  trans¬ 
ferred  to  VAX. 

Dimensions  of  Alpha- 

Many  dimensions  need 

numeric  Constants 

increasing.  Make 
changes  noted  in: 

ADD,  DELETE, 

DELMSG,  DISPLAY, 
FRAMER,  HELP,  LINK, 
MESSAGE,  PICKID, 
OPTION,  SCALE, 
STARTUP,  ZOOM 

Unnecessary  Named 

/TERMTYP/ 

Remove  noted  lines 

Common  TERMTYP  and 

ITYPE 

in: 

References  to 

DISPLAY,  FRAMER, 

Variable  ITYPE 

HELP,  MOVCRSR, 
NEWWNDO,  PLCTALL, 
SCGRID,  SETCOM, 
SITEPLT,  STARTUP 

Code  Changes 

DO  20  1-1,4 

K-0 

FRAMER 

MI«I*MH 

DO  20  1-1,10,3 

K-K+l 

MI«K*MH 

Calls  to  Mass 

OPENMS 

STARTUP 

Storage  Subroutines 

READMS 

STARTUP,  DBIO 

WRITMS 

ENDUP,  DBIO 

CLOSMS 

ENDUP 

APPENDIX  B 


DATA  BASE  FORMAT 


FILE-B,  the  data  base  used  by  the  P-Card  Data  Definition  System 
consists  of  eight  variable  length,  random  access,  mass  storage  records. 
This  appendix  will  describe,  in  detail,  the  contents  of  each  record,  the 
record  structure  (all  records  are  similarly  structured  except  Record  1) , 
and  the  method  used  to  access  data  elements  within  each  record. 

Contents 

Record  1  -  This  is  a  32  word  record  containing  basic  system 

definition  data.  All  data  in  this  record  is  resident 
in  memory  during  execution  of  all  PDDS  programs  and 
includes  the  following: 

a.  Location  of  the  environment  boundaries  (4  words)  - 
XMIN,  XMAX,  YMIN,  YMAX. 

b.  A  count  of  the  number  of  active  sites,  by  type,  at 
any  given  time  (8  words) . 

1  —  //  Active  EW  sites 

2  -  //  Active  GP  sites 

3  -  #  Active  HQ  sites 

4  -  #  Active  GC  sites 

5  -  //  Active  AF  sites 

6  -  #  Active  FC  sites 
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7 


It  Active  SA  sites 


8  -  Total  It  Active  sites 

c.  The  maximum  number  of  each  site  type  permitted 
(8  words).  Same  as  b. 

d.  The  number  of  words  in  each  mass  storage  record 
(8  words).  Same  as  b.  excepting  word  It 3  which  is 
included  as  a  dummy  for  programming  convenience 
since  there  is  no  HQ  record. 

e.  Primary  and  secondary  strategic  headquarters  site 
numbers  (2  words) . 

f.  A  flag  used  to  identify  prior  data  base  accesses. 

g.  The  altitude  of  penetrating  aircraft. 

Record  2  -  This  record  contains  the  site  number,  X-Y  location 

coordinates,  and  coded  function(s)  of  each  site  in  the 
environment.  Its  length,  in  words,  is  four  times  the 
maximum  number  of  sites  (as  identified  in  Record  1) 
permitted  in  the  scenario.  The  data  is  ordered  by  site 
number  within  the  record  and  is  completely  memory 
resident  during  execution  of  each  system  program. 

The  remaining  seven  mass  storage  records  contain  data  peculiar  to  a 
particular  site  type.  The  length  of  each  record  is  determined  by  the  number 
of  data  elements  per  site  included  in  the  record  multiplied  by  the  maximum 
number  of  each  type  of  site  permitted  in  the  scenario.  This  determination 
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is  made  by  the  SETUP  program.  These  records  are  each  core  resident  only 
when  action  is  being  performed  on  data  contained  in  them.  As  with 
Record  2,  data  in  each  of  these  records  is  ordered  on  site  number. 


Record  3 


Record  4 

Record  5 


Record  6 


This  record  contains  Early  Warning  site  characterization 
data  and  includes  nineteen  data  elements  per  site,  as 
follows: 

a.  Site  Number 

b.  Correlator  Switch 

c.  Acquisition  Radar  Identifiers  (4) 

d.  Height  Finder  Radar  Identifiers  (3) 

e.  Primary  and  Secondary  Group  Center  Numbers  (2) 

f.  Site  Responsibility  Ranges  (8) 

This  record  contains  only  Group  Center  site  numbers. 

This  record  contains  Ground  Control  Intercept  site 
data  with  six  data  elements  per  site: 

a.  Site  Number 

b.  Site  Name 

c.  Search  Radar  Identifier 

d.  Height  Finder  Radar  Identifier 

e.  Primary  and  Secondary  Airfield  Numbers  (2) 

Airfield  characterization  data  with  three  data  elements 
per  site  is  contained  in  this  record,  as  follows: 

a.  Airfield  Number 
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b.  Airfield  Name 


c.  Airfield  Type 

Record  7  -  This  record  contains  Fire  Control  Center  data  with 

seven  data  elements  per  site: 

a.  Site  Number 

b.  Site  Name 

c.  Search  Radar  Identifier 

d.  Height  Finder  Radar  Identifier 

e.  Coordinates  of  Control  Zone  Centroid  (2) 

f.  Radius  of  Control  Zone  Centroid 

Record  8  -  This  record  contains  Surface-to-Air  Weapon  (AAA  and 

SAM)  site  data  with  six  data  elements  per  site  as 
follows: 

a.  Site  Number 

b.  Site  Name 

c.  Fire  Control  Center  Site  Number  (for  Strategic 
Sites)  or  Battalion  Site  Number  (for  Tactical  Sites). 

d.  Tracking  Radar  Identifier 

e.  Acquisition  Radar  Identifier 

f.  Height  Finder  Radar  Identifier 

Structure 

Record  1  consists  of  a  straightforward  sequential  assignment  of  the 
Included  data  elements  and  should  require  no  additional  explanation.  How- 
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ever,  since  Records  2  through  9  contain  multiple,  non-uniform,  data  fields, 
a  storage  mechanism  is  employed  that  conveniently  permits  common  access  to 
each  record  type. 

The  mass  storage  input/output  routines  treat  each  record  as  an  array 
during  the  transfer  between  central  memory  and  mass  storage.  Therefore, 
it  is  necessary  to  insure  that  all  data  is  stored  contiguously  while  in 
central  memory.  To  accomplish  this,  one  large,  single-dimensioned  array, 
called  REC,  is  provided  by  all  system  programs  to  hold  site  data  while  in 
memory.  Then,  whether  in  core  or  on  mass  storage,  the  storage  structure 
of  each  record  is  the  same  with  like  data  elements  stored  in  ordered 
format,  by  fields.  That  is,  when  a  record  containing  N  sites  is  read 
into  memory,  the  first  N  words  in  REC  contain  the  entire  first  data  field 
of  the  record,  the  second  N  words  contain  the  second  data  field,  and  so 
on  through  all  fields  included  in  the  record.  Since  the  data  is  ordered, 
data  elements  at  the  k— ,  (N  +  k)— ,  (2N  +  k)— ,  .  .  .  locations  within  the 
array  all  pertain  to  the  same  site. 

This  storage  format  is  particularly  convenient  during  execution  of 
the  UPDATE  program  where  it  is  often  desirable  to  have  two  site  records  in 
memory  concurrently.  In  this  situation,  the  primary  record  data  is  loaded 
beginning  at  the  first  word  of  REC  and  the  secondary  record  data  is  loaded 
beginning  at  the  first  available  word  following  the  primary  record  data. 
Since  the  internal  format  of  each  record  varies,  this  format  significantly 
simplifies  accessing  individual  data  elements  within  either  record. 

Access 

To  access  a  particular  data  element  within  a  record,  provided  the 
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Figure  B-l.  REC  Array  Format 


record  has  been  read  into  REC,  a  program  requires  only  knowledge  of  the 
data  field  containing  the  elements  plus  the  site  and  word  count  data 
identified  in  Record  1.  Figure  B-l  illustrates  the  relationship  of  data 
elements,  fields,  and  the  primary  and  secondary  site  records  as  they  are 

A,  1 

located  in  REC.  Thus,  to  access  the  i—  element  in  the  j —  field  in  a 
record  containing  N  sites,  the  program  need  only  make  the  simple  computa¬ 
tion  (j-l)*N+i  to  obtain  the  array  address  of  the  desired  element.  If 
the  element  is  located  in  the  secondary  record,  the  number  of  words  which 
comprise  the  primary  record  must  be  added  to  the  result  of  the  computation. 
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APPENDIX  C 


TEKTRONIX  SUBROUTINE  DEFINITION 


Much  of  the  graphics  capability  inherent  in  the  UPDATE  program  is 
provided  by  routines  from  the  TEKTRONIX  PLOT-10  and  Advanced  Graphing  II 
(AG-II)  software  libraries.  This  appendix  will  identify  those  routines 
used  in  support  of  UPDATE  program  objectives  and  briefly  define  their 
purpose.  For  further  clarification,  the  reader  is  referred  to  the  TCS 
PLOT-10  User's  Manual  (Ref  11)  and  the  Advanced  Graphing  II  User's  Manual 
(Ref  12). 

The  following  routines  from  the  TEKTRONIX  software  libraries  are 
incorporated  in  the  PDDS  interactive  graphics  program,  UPDATE: 


ANCHO  -  Outputs  one  TEKTRONIX  ASCII  Decimal  Equivalent  (ADE) 
character  to  the  display  screen.  An  ADE  character  is 
defined  by  an  integer  representation  of  an  ASCII  character. 
ANCHO  is  used  to  display  the  scale/zoom  level  in  the  upper 
right  corner  of  the  menu  area. 


ANMODE  -  This  routine  is  used  to  dump  the  TEKTRONIX  output  buffers 
prior  to  all  FORTRAN  input/output  activities.  If  not 
called,  some  graphics  data  may  be  lost. 

ANSTR  -  Outputs  a  string  of  ADE  characters  to  the  display  screen. 
Used  to  display  the  geographic  coordinates  selected 
through  use  of  the  LOCATE  option. 

AOUTST  -  Outputs  an  array  of  alphanumeric  (ASCII)  characters  to  the 


display  screen.  AOUTST  is  used  to  display  all  messages 
queries  and  prompts. 


BELL  - 


CHRSIZ  - 


DASHA  - 


DCURSR  - 


DRAWA  - 


DRWABS 


DWINDO  - 


Enables  the  terminal  bell.  This  call  is  invoked  each  time 
the  OPTION  prompt  is  displayed. 

The  TEKTRONIX  4014/4016  terminals  have  four  character  sizes 
with  which  to  display  character  data.  CHRSIZ  is  used  to 
designate  the  desired  size.  All  UPDATE  displays  use  the 
smallest  available  size. 

Similar  to  DRAWA  except  dashed  rather  than  solid  lines  are 
drawn  within  the  display  area.  Dashed  lines  are  used  to 
designate  secondary  command  and  control  linkages. 

Activates  the  terminal  crosshairs  on  the  display  screen 
and  accepts  input  data  when  a  terminal  key  is  struck. 

DCURSR  is  used  in  all  pick  and  locate  functions  in  UPDATE. 

This  routine,  in  conjunction  with  DWINDO,  is  used  to  enable 
line  drawing  within  the  display  area.  Lines  which  might 
extend  beyond  the  display  area  are  "clipped"  at  the 
boundary.  DRAWA  is  used  to  draw  circles,  links,  and  site 
symbols. 

The  absolute  line  drawing  routine  -  one  of  the  TEKTRONIX 
primitives.  Used  to  draw  all  borders  and  is  called  by 
DRAWA  to  provide  actual  line  drawing  capability. 

Defines  the  display  area,  or  window,  based  on  scenario 
boundary  data  provided.  DWINDO  identifies  the  Initial 
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environment  window  and  is  used  to  SCALE  or  ZOOM  in  and 


ERASE  - 


FFORM  - 


FINITT  - 


IN  ITT  - 


MOVABS  - 


MOVEA  - 


TWINDO  - 


out  of  the  display  by  redefining  the  window  area  when 
those  options  are  invoked. 

Clears  the  display  screen.  ERASE  is  called  immediately 
ahead  of  the  generation  of  all  new  displays. 

Converts  a  real  number  into  an  ADE  character  string  for 
subsequent  output  to  the  display  screen.  Used  in 
conjunction  with  ANSTR  to  output  X-Y  coordinates  defined 
with  the  LOCATE  option. 

Terminates  all  graphics  activities  and  clears  the 
TEKTRONIX  buffer  areas. 

Initializes  the  TEKTRONIX  Terminal  Status  Area  (TCS  Common) 
and  establishes  the  character  transmission  rate  between 
the  terminal  and  the  host  system. 

Used  to  move  the  graphic  beam  position  from  point  to 
point  -  a  second  TEKTRONIX  primitive.  MOVABS  is  used  in 
conjunction  with  all  line  drawing  activities. 

Used  with  DRAWA  and  DWINDO  in  all  display  area  line 
drawing  activities. 

Defines  that  portion  of  the  display  screen  in  which  the 
display  area  is  to  be  drawn.  Identifies  the  screen 
coordinates  of  the  display  window  boundaries. 
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APPENDIX  D 


UPDATE  SUBROUTINE  DEFINITION 


The  UPDATE  program  contains  a  series  of  thirty-nine  functionally 
independent  subroutines  and  functions.  This  appendix  identifies  each 
routine  with  associated  parameters  and  provides  a  brief  definition  of 
its  purpose  and  how  it  is  used  within  the  context  of  the  program. 

Routines  that  identify  user-selectable  options  are  documented  in 
the  PDDS  System  User's  Guide,  Appendix  E,  but  will  be  included  in  this 
appendix  for  completeness.  The  reader  is  referred  to  the  User's  Guide 
for  details  concerning  their  use. 

The  following  routines  comprise  the  PDDS  interactive  graphics 
program,  UPDATE: 

SUBROUTINE  ADD 

User-selectable  option. 

SUBROUTINE  BISECT  (NUM,  IRAY,  MAX,  ID) 

A  binary  search  routine  called  from  many  points  within  UPDATE  to 
return  the  array  index  (ID)  of  the  element  (NUM)  in  the  array  (IRAY)  of 
length  (MAX). 

SUBROUTINE  CHANGE 

User-selectable  option. 

SUBROUTINE  CIRCALL 

This  routine  is  actually  called  when  the  user-selectable  option 
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CIRCLE  is  entered.  Its  purpose  is  to  determine  which  sites  are 
currently  displayed  and  invoke  the  circle  drawing  routine,  CIRCLE,  for 
each  applicable  site. 

SUBROUTINE  CIRCLE  (XO,  YO,  RAD) 

Draws  a  circle  of  radius  RAD  about  the  point  (XO,  YO).  The  circle 
is  drawn  as  a  series  of  16  straight-line  segments  per  quadrant,  each 
quadrant  drawn  separately. 

SUBROUTINE  DBIO  (10) 

The  primary  interface  between  the  UPDATE  program  and  mass  memory. 
Depending  upon  the  contents  of  the  parameter  10,  DBIO  reads  or  writes 
site  records  from  or  to  mass  storage  through  the  mass  storage  input/output 
routines  READMS  and  WRITMS. 

SUBROUTINE  DELETE 

User-selectable  option. 

SUBROUTINE  DELMSG 

Low  level  message  interface  between  the  program  and  the  user,  invoked 
only  from  the  DELETE  subroutine.  Included  to  reduce  duplicate  code. 

SUBROUTINE  DISPLAY 

User-selectable  option. 

SUBROUTINE  ENDUP 

Program  termination  routine.  Ensures  that  all  mass  storage  records 
are  current,  sorted,  and  properly  stored.  Closes  the  mass  storage  file, 
clears  TEKTRONIX  buffers,  and  terminates  program  execution. 


66 


SUBROUTINE  FRAMER 


Draws  an  outline  around  the  display  and  menu  areas  and  writes  the 
option  names  in  the  menu  area.  The  outline  around  the  display  area 
defines  the  boundaries  outside  of  which  no  graphics  drawing  may  occur. 

SUBROUTINE  HELP 

User-selectable  option. 

SUBROUTINE  LINK  (LK) 

User-selectable  option. 

SUBROUTINE  LOCATE 

User-selectable  option. 

SUBROUTINE  MESSAGE  (NC,  M) 

Prints  informative  and  diagnostic  messages,  questions,  and  prompts 
in  the  I/O  area.  This  routine  provides  a  single  storage  location  for  I/O 
strings  normally  issued  from  several  higher  level  routines,  thus  reducing 
memory  requirements  for  the  total  program.  NC  is  a  positioning  parameter 
passed  on  to  MOVCRSR;  M  is  the  message  number  to  be  printed. 

SUBROUTINE  MOVCRSR  (NC) 

Positions  the  TEKTRONIX  cursor  for  message  printout  in  the  I/O  area. 
Without  this  routine,  messages  would  be  randomly  printed  on  the  display 
surface,  often  incurring  unintelligible  overprints.  The  NC  parameter  is 
a  vertical  positioning  factor;  horizontal  positioning  is  fixed. 

SUBROUTINE  MOVSITE 

User-selectable  option. 
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SUBROUTINE  NEWWNDO  (XMIN,  XMAX,  YMIN,  YMAX) 


Resets  the  display  area  window  borders  each  time  the  SCALE,  ZOOM, 
or  RETURN  user  options  are  invoked  and  initiates  redrawing  of  the  display 
at  the  new  scale  level.  Parameters  define  the  lower- left  and  upper-right 
corners  of  a  square  geographic  area. 

SUBROUTINE  NUMBER  (IR,  NMBR,  INTNO,  REALNO ,  IER) 

Converts  alphanumeric  data  contained  in  the  array  NMBR  to  either 
a  5-digit  integer  number,  INTNO,  or  a  maximum  10-digit  real  number, 

REALNO,  depending  on  IR.  IER  is  a  flag  used  to  indicate  a  valid  or 
invalid  conversion. 

SUBROUTINE  OPTION 

This  is  the  central  user-program  interface  routine  through  which  all 
option  entries  occur.  Each  entry  is  validated  and  a  branch  to  the 
appropriate  routine  is  invoked.  An  error  message  is  issued  when  an  invalid 
option  (unknown  character  string)  is  entered. 

SUBROUTINE  PICK  (IX,  IY,  NUM,  IER) 

Determines  whether  a  valid  pick  was  implemented  by  the  user.  A  valid 
pick  occurs  when  the  terminal  crosshairs  intersect  over  a  unique,  displayed 
site.  The  parameters  IX  &  IY  are  the  screen  coordinates  of  the  crosshair 
intersection  and  NUM  is  the  site  number  returned  from  a  valid  pick.  IER 
is  a  flag  used  to  indicate  an  erroneous  pick  which  will  occur  when  cross¬ 
hairs  are  outside  the  display  area,  when  no  displayed  site  falls  within 
an  epsilon  distance  (1/2  the  symbol  size)  of  the  intersection,  or  when 
multiple  sites  fall  within  the  same  epsilon  distance  and  a  unique  site 
cannot  be  identified. 
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SUBROUTINE  PICKID 


User-selectable  option. 

SUBROUTINE  PLOTALL 

Plots  all  sites  and  site  functions  that  fall  within  the  display  area 
window  when  the  user  specifies  that  "ALL"  sites  should  be  plotted  in 
response  to  a  DISPLAY  option  prompt. 

SUBROUTINE  PTLOC  (IX,  IY,  XP,  YP,  IER) 

Routine  converts  screen  coordinates  (IX,  IY)  to  user  (world) 
coordinates  (XP,  YP) .  Sets  an  error  flag  IER  if  the  screen  coordinates 
are  outside  the  display  area  window. 

FUNCTION  RADIUS  (NTYP,  ID,  JD) 

A  function  subroutine  which  returns  the  maximum  radar  range  for 
EW,  GC,  and  FC  sites  and  the  effective  weapon  range  for  AAA  and  SAM  sites. 
The  range  is  used  as  the  radius  when  the  CIRCLE  option  is  in  effect.  The 
site  type  is  defined  by  the  parameter  NTYP.  ID  is  the  array  index  of  the 
site  number  in  the  site  record  and  JD  is  the  array  index  of  the  site 
number  in  the  master  record.  EW,  GC,  and  FC  radar  ranges  are  determined 
via  table  look-up;  AAA  and  SAM  ranges  are  a  function  of  the  altitude  of 
penetrating  aircraft  and  are  computed  using  linear  interpolation  pro¬ 
cedures  . 

SUBROUTINE  REDRAW 

User-selectable  option. 
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SUBROUTINE  RE SETT 


This  is  the  user-selectable  option  RESET.  The  routine  name  has 
been  modified  to  avoid  conflict  with  a  TEKTRONIX  PLOT- 10  library 
subroutine,  RESET. 

SUBROUTINE  RETURN 

User-selectable  option. 

SUBROUTINE  SCALE 

User-selectable  option. 

SUBROUTINE  SCGRID 

This  subroutine  draws  the  4x4  square  grid  which  overlays  the  dis¬ 
play  area  when  the  SCALE  option  is  specified  and  writes  the  identification 
letters  in  the  upper  left  comer  of  each  square. 

SUBROUTINE  SETCOM 

The  GRAFIX  common  area  initialization  routine.  All  common  area 
variables  not  initialized  in  STARTUP  using  data  stored  in  the  data  base 
are  Initialized  in  this  routine.  The  initial  display  area,  or  window, 
is  also  defined  here. 

SUBROUTINE  SITENUM 

This  is  an  interface  routine  between  many  calling  routines  and  sub¬ 
routine  PICK.  It  is  included  in  UPDATE  principally  to  eliminate  duplica¬ 
tion  of  code  required  to  evaluate  whether  a  valid  or  erroneous  pick  was 
attempted  by  the  user.  Diagnostic  messages  associated  with  erroneous 
pick  attempts  are  initiated  here. 
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SUBROUTINE  SITEPLT 


Used  to  plot  site  symbols  of  a  unique  site  or  site  pair  (compare 
with  PLOTALL) .  From  data  in  GRAFIX  common  variables,  SITEPLT  determines 
whether  a  completely  new  display  is  required  and  which  site  or  weapon 
types  are  to  be  displayed.  It  then  plots  the  primary  headquarters  (if 
it  is  defined)  and  searches  the  master  record  for  the  index  of  each  site 
to  be  plotted.  The  index  is  passed  to  subroutine  STPLOT  where  the  actual 
symbol  (and  CIRCLE,  if  necessary)  plotting  is  initiated.  The  New-Site 
buffer  is  checked  for  additional  sites  of  the  type  currently  being  plotted 
and  links  between  site  pairs  are  displayed  if  the  link  switch  is  set. 

SUBROUTINE  SORTER 

This  is  an  implementation  of  a  shell  sort  algorithm  modified  to 
enable  sorting  of  site  records  with  a  variable  number  of  fields.  The 
routine  is  highly  efficient,  particularly  when  a  large  number  of  sites 
are  included  in  a  record,  and  is  used  extensively  throughout  execution 
of  the  program  to  maintain  ordering  of  the  master  and  all  site  records, 

SUBROUTINE  SQWINDO 

In  order  to  eliminate  display  area  distortion  by  having  unequal  X 
and  Y  window  boundaries,  an  exactly  square  geographic  area  is  displayed 
at  all  times.  SQWINDO  ensures  this  by  defining  equal  X  and  Y  boundaries 
based  on  the  maximum  of  the  currently  specified  boundary  distances. 

SUBROUTINE  STARTUP 

The  UPDATE  initialization  routine.  STARTUP  opens  the  mass  storage 
file  and  invokes  all  common  area  initialization  procedures,  including 
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those  required  by  the  TEKTRONIX  graphics  subroutines.  It  then  displays 
introductory  message  information  and  initiates  display  of  the  first  set 
of  site  data  identified  by  the  user. 

SUBROUTINE  STPLOT 

Initializes  the  display  of  symbols  used  to  represent  the  various 
site  types  in  the  PDDS  system.  If  the  CIRCLE  switch  is  set,  the  radius 
and  circle  drawing  routines  are  also  invoked  here.  This  is  another  routine 
included  in  UPDATE  for  the  purpose  of  eliminating  duplicate  code. 

SUBROUTINE  SYMBL 

The  actual  site  symbol  drawing  routine.  Each  of  the  twelve  site 
symbols  and  the  "X"  used  to  indicate  deleted  sites  and  linkages  is 
defined  and  drawn  here  using  a  series  of  primitive  TEKTRONIX  move  and 
draw  subroutines. 

SUBROUTINE  ZOOM 

User-selectable  option. 
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The  PDDS  provides  a  means  of  generating  defense  element  data  for 
inclusion  in  the  input  data  set  of  the  Avionics  Air  Defense  Evaluation 
Model  (AADEM) .  This  user's  guide  describes  execution  and  operation 
procedures  for  each  of  the  programs  included  in  the  PDDS. 

The  PDDS  executes  on  the  CYBER  74/175  Computer  Systems  at  the  ASD 
Computer  Center  and  is  controlled  through  the  use  of  CYBER  Control 
Language  (CCL)  catalogued  procedures.  These  procedures  relieve  the  user 
of  all  file  manipulation  responsibilities  necessary  with  execution  of 
each  program  by  invoking  all  required  actions  for  him.  The  user's  only 
responsibility  is  initiation  of  the  appropriate  procedure  -  a  single 
statement  entry.  Each  procedure  is  identified  by  the  same  name  as  the 
program  it  is  responsible  for  processing. 

Program  execution  on  the  VAX  11/780  (the  PDDS  target  system)  has  not 
been  defined  at  this  writing  due  to  the  non-availability  of  system 
documentation.  Consequently,  all  operational  procedures  described  in  this 
user's  guide  will  apply  only  to  the  CYBER  systems.  It  is  hoped  that 
procedures  comparable  with  CCL  procedures  may  be  implemented  on  the  VAX. 

Three  of  the  four  system  programs  are  batch  executed  and  require 
minimal  user  preparation.  These  are  the  SETUP,  APEND2,  and  MSDUMP  programs 
and  will  be  discussed  first.  The  remaining  program  is  the  Interactive 
graphics  program,  UPDATE,  and  requires  extensive  user  interaction.  The 
majority  of  this  appendix  will  address  operation  of  the  UPDATE  program 
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with  individual  attention  being  given  to  each  of  the  user-selectable 
options  through  which  the  program  is  controlled. 

The  SETUP  Program 

This  program  screens  the  initial  set  of  input  data  provided  on 
FILE-A,  identifies  each  primary  defense  element  within  the  environment, 
eliminates  duplicate  and  unnecessary  data,  and  creates  the  system  data 
base,  FILE-B. 

Batch  execution  is  enabled  on  the  CYBER  systems  using  the  following 
control  cards: 

PCARD,  CM100000,  T40,  1040,  STANY.  Id-Number,  Name,  Phone 
BEGIN, SETUP, PCARD. 

6/7 /8/9  (Multipunched  EOF  Card) 

where:  Id-Number  is  th  ~  user's  computer  identification  number  under  which 
all  required  files  are  catalogued. 

SETUP  is  the  CCL  procedure  name. 

PCARD  is  the  CCL  file  containing  the  CCL  procedure. 

The  APEND2  Program 

This  program  is  used  to  merge  the  site  dependent  data  from  FILE-B, 
the  data  base,  with  the  site  independent  data  stored  on  FILE-C.  The 
resultant  product  is  a  complete,  properly  formatted  set  of  P-Card  data 
for  inclusion  in  the  AADEM  input  data  set. 

No  user  inputs  are  required  for  this  program.  Batch  execution  is 
initiated  with  the  following  control  cards: 
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PCARD,  CM100000,  T40,  1040,  STANY.  Id-Number,  Name,  Phone 
BEGIN,  APEND2 ,  PCARD. 

6/7 /8/9 

The  MSDUMP  Program 

The  MSDUMP  program  provides  a  hardcopy  printout  of  the  contents  of 
the  mass  storage  data  base  file,  FILE-B.  This  enables  the  user  to  review, 
at  any  time,  the  general  contents  of  all  records  and  is  quite  beneficial 
for  data  validation  and  inspection  purposes. 

The  printout  is  formatted  by  individual  mass  storage  records  with 
fields  or  data  elements  within  each  record  properly  annotated  for  read¬ 
ability. 

No  user  inputs  are  required.  Execution  is  initiated  as  follows: 

PCARD,  CM 100000,  T40,  1040,  STANY.  Id-Number,  Name,  Phone 
BEGIN,  MSDUMP,  PCARD. 

6/7/8/9 

The  UPDATE  Program 

I.  Introduction.  The  UPDATE  program  is  the  heart  of  the  PDDS.  It 
consists  of  an  interactive  computer  graphics  program  through  which  the 
user  defines  and/or  modifies  the  various  site  parameters  associated  with 
each  defense  site  in  the  environment.  The  program  is  designed  to  be 
executed  using  CDC  INTERCOM  procedures;  the  graphics  display  terminal 
must  be  a  TEKTRONIX  4014/4016  type  device. 

A.  As  indicated  above,  program  execution  is  initiated  through  the 
use  of  catalogued  procedures.  After  standard  LOGIN  to  INTERCOM  has  been 
accomplished,  the  following  response  to  the  INTERCOM  prompt  "COMMAND"  is 
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entered: 


COMMAND  -  BEGIN, UPDATE, PCARD 

CCL  then  performs  all  required  file  manipulation  and  control  procedures 
necessary  to  begin  execution. 

B.  During  program  execution,  all  man-machine  interaction  is 
accomplished  using  a  conversational  medium  of  program  prompt-user  response. 
User  response  is  invoked  through  typed  input  via  the  terminal  keyboard  or 
through  positioning  of  the  crosshairs  displayed  on  the  terminal  screen. 
Each  typed  response  must  be  followed  by  a  carriage  return,  denoted  (CR) , 
and  each  response  is  validated  by  the  program  prior  to  any  subsequent 
action.  If  the  response  is  invalid,  the  program  will  issue  a  message  such 
as: 

BAD  REPLY  -  TRY  AGAIN 

and  repeat  the  prompt.  A  short,  informative  message  may  also  be  printed 
depending  on  the  type  of  error  involved.  If  crosshair  positioning  is 
required,  the  displayed  crosshairs  may  be  moved  to  the  desired  location 
by  rolling  the  thumbwheels  located  at  the  right  of  the  terminal  keyboard. 
Two  thumbwheels  are  provided  -  one  to  move  the  crosshair  horizontally, 
the  other  to  move  it  vertically.  Crosshair  positioning  errors  occur 
when  the  intersection  is  outside  the  display  area  and  will  produce  error 
messages  similar  to  those  described  above. 

C.  The  program  systematically  leads  the  user  through  its  execution 
by  displaying  clear,  understandable  prompts  whenever  user  input  is 
required.  The  most  common  prompt  is: 

OPTION: 
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wherein  appropriate  user  response  is  to  type  in  an  option  verb  indicating 
the  action  to  be  invoked.  Valid  options  are  always  displayed  in  the  menu 
box  located  beneath  the  display  area.  The  full  option  name  may  be 
entered,  however,  only  the  first  three  letters  of  the  name  are  used  by 
the  program  to  validate  the  entry.  Thus,  an  entry  of  DEL  is  sufficient 
for  valid  specification  of  the  DELETE  option.  See  Sec.  Ill  for  a 
description  of  all  program  options.  Other  prompts  or  messages  may  be 
output  by  the  program  during  the  processing  of  various  options.  These 
define  data  entry  points  and  enable  an  easy  means  of  man-machine  communi¬ 
cation. 

D.  The  display  surface  is  divided  into  three  major  areas  -  the 
I/O  area,  the  display  area,  and  the  menu  area.  (See  Figure  7) 

1.  The  I/O  area  is  the  entire  left  third  of  the  screen  surface. 

It  is  in  this  area  that  narrative  interaction  between  the  user 
and  the  program  is  displayed.  All  prompts,  messages,  and  lists 
are  output  to  this  area  by  the  program  and  all  user  inputs  are 
echo  printed  in  this  area  by  the  terminal. 

2.  The  display  area  is  the  large,  square  outlined  area  that 
occupies  most  of  the  upper  right  portion  of  the  screen  surface. 

It  is  in  this  area  that  all  graphical  output  appears.  This  area 
is  often  referred  to  as  the  "window". 

3.  The  menu  area  is  the  rectangular  area  outlined  immediately 
below  the  display  area.  Within  this  area,  all  valid  option  verbs 
are  listed.  A  small  box  in  the  upper  right  corner  of  this  area 
contains  the  scale  (zoom)  level  of  the  current  display. 
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E.  All  options  except  REDRAW,  RESET,  and  STOP  require  some  form  of 
user  interaction  in  order  to  complete  their  specified  task.  If,  during 
the  progress  of  any  of  these  options,  the  user  no  longer  deems  execution 
of  this  option  necessary,  he  may  enter  an  "X"  in  response  to  any  prompt 
or  query  issued  by  the  program.  This  will  void  all  current  option 
activity  and  afford  him  the  opportunity  to  select  another  option. 

II.  Execution.  Execution  of  the  UPDATE  program  begins  following  entry 
of  the  CCL  control  statement  described  above.  Execution  begins  with  a 
clear  screen  and  a  series  of  messages  and  questions  to  the  user.  The 
form  of  messages  depends  upon  whether  previous  UPDATE  runs  have  been  made 
against  the  current  data  base  or  whether  this  is  the  initial  run. 

A.  If  the  latter  is  true,  displayed  information  is  as  follows: 

WELCOME  TO  UPDATE 

THIS  IS  MODIFICATION  NO.  1 

FOR  PROPER  DISPLAY  OF  SAM/AAA  RANGES, 

ACFT  ALTITUDE  MUST  BE  KNOWN  BY  UPDATE 

ENTER  ACFT  ALTITUDE  - 

DO  YOU  NEED  HELP?  Y/N 

A  No  response  permits  program  continuation. 

A  Yes  response  will  cause  generation  of  a  new  display 
showing  a  site  symbol/abbreviation  table  and  a 
definitive  list  of  user-selectable  options  (Figure  H-12) 
followed  by  the  prompt: 

TO  CONTINUE.  ENTER  -  GO 
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A  GO  entry  permits  program  continuation. 

B.  If  the  current  UPDATE  run  is  not  the  initial  run,  the  following 
preliminary  information  is  displayed: 

WELCOME  TO  UPDATE 
THIS  IS  MODIFICATION  NO.  x 
ACFT  ALTITUDE  =  xxxxxxx 
CHANGE  ACFT  ALTITUDE?  Y/N 


If  No  is  entered,  displayed  information  continues.  If  Yes  is  entered, 
the  prompt: 


ENTER  ACFT  ALTITUDE  - 


is  displayed,  and  a  response  is  required.  Information  then  continues: 
SITE  INFORMATION: 


#  EW  SITES  =  xxxx 
It  GP  SITES  =  xxxx 
It  HQ  SITES  =  xxxx 
It  GC  SITES  =  xxxx 
It  AF  SITES  =  xxxx 
It  FC  SITES  =  xxxx 
It  SA  SITES  =  xxxx 
It  TA  SITES  -  xxxx 
TOTAL  ACTIVE  SITES  -  xxxxx 


MAX  EW  =  xxxx 
MAX  GP  =  xxxx 
MAX  HQ  =  xxxx 
MAX  GC  =  xxxx 
MAX  AF  ■  xxxx 
MAX  FC  =  xxxx 
MAX  SA  “  xxxx 
MAX  TA  *  xxxx 
MAX  TOTAL  -  xxxxx 


DO  YOU  NEED  HELP?  Y/N 

A  No  response  permits  program  continuation. 
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A  Yes  response  causes  generation  of  a  new  display  showing  a 
site  symbol/abbreviation  table  and  a  definitive  list  of 
user  options  (Figure  H-12)  followed  by  the  prompt: 

TO  CONTINUE,  ENTER  -  GO 
which  then  permits  program  continuation. 

C.  At  the  beginning  of  execution,  the  UPDATE  program  is  presumptuous 
in  that  it  expects  the  user  to  want  to  display  at  least  one  set  of  site 
data,  even  if  he  does  not  desire  to  make  any  changes.  Thus,  the  prompt: 

READY  TO  BEGIN  PROCESSING 

ENTER  SITE  FUNCTION  OR  "ALL" 

is  printed  in  the  I/O  area  and  the  user  must  enter  the  abbreviation  for 
the  desired  site  or  site  pair  (see  Table  E-I)  or  the  word  "ALL".  The 
appropriate  display  is  then  generated  as  described  in  Sec.  III-E. 

D.  The  completed  display  will  include  the  menu  box  with  all  valid 
options  listed  and  the  prompt: 

OPTION: 

at  the  top  of  the  I/O  arsa.  Processing  has  now  progressed  to  the  heart 
of  the  UPDATE  program,  for  it  is  here  that  the  work  of  making  all  the 
required  site  modifications  occurs.  Valid  responses  to  the  OPTION  prompt 
are  listed  in  the  menu  box  and  are  described,  in  detail,  in  Sec.  Ill 
below.  An  input  option  will  generate  a  series  of  actions  in  the  display 
area  for  visual  validation  and,  concurrently,  modify  appropriate  parameters 
within  the  data  base.  Some  options  will  require  additional  user  inputs; 
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TABLE  E-I 

Site  Identification  Table 


SITE  TYPE 

SYMBOL 

ABBREVIATION 

FUNCTION 

Headquarters 

® 

HQ 

STRATEGIC 

Early  Warning  Site 

o 

EW 

STRATEGIC 

Group  Center 

G 

GP 

Ground  Control  Intercept 

I 

GC 

STRATEGIC 

Airfield 

D 

AF 

Fire  Control  Center 

M 

FC 

Surface-Air-Weapon 

SA 

STRATEGIC 

Anti-Aircraft 

Missile 

A 

Tactical 

TA 

Battalion 

* 

BA 

Super-Battalion 

SB 

TACTICAL 

Division 

m 

DV 

Army  Headquarters 

® 

AH 

all  requirements  are  made  known  to  the  user  through  easily  understood 
prompts.  If,  however,  the  user  does  not  understand  the  prompt,  the 
response  HELP  (see  Sec.  III-F)  may  be  entered  and  clarification  of  the 
appropriate  response  is  provided. 

E.  User-program  interaction  thus  continues  through  a  series  of 
prompt/response  actions  as  the  program  loops  through  the  OPTION  prompt. 
When  the  user  has  satisfactorily  completed  all  required  modifications 
(at  this  sitting),  selection  of  the  STOP  option  will  return  control  to 
the  UPDATE  procedure  control  sequence.  On  completion  of  the  procedure 
sequence,  control  returns  to  the  Cyber  INTERCOM  system  and  the  prompt: 

COMMAND- 

is  displayed.  At  this  point,  the  user  is  completely  free  of  the  P-Card 
Definition  System  and  may  either  LOGOUT  of  INTERCOM,  or  continue  with 
other  processing  requirements. 

III.  Option  Definition  and  Usage.  The  following  is  a  definitive  list 
of  all  options,  showing  their  implementation  and  usage  through  example, 
where  applicable.  Most  descriptions  reference  sample  figures  for 
clarification. 

A.  ADD  - 

This  option  is  used  to  add  a  new  site  to  the  environment  or  to  add 
an  additional  function  to  an  existing  site.  Any  functionally  valid 
site  may  be  added,  and  will  be  immediately  displayed,  at  any  time 
regardless  of  whatever  site  types  are  being  displayed  at  that  time.  If, 
however,  the  added  site  is  not  the  same  type  as  those  currently  active. 
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it  will  not  appear  on  the  screen  when  subsequent  displays  are  generated, 
until  such  time  as  its  type  is  selected  to  be  displayed  by  the  user. 

When  the  ADD  option  is  specified,  the  crosshairs  appear  and  the 
prompt: 

LOCATE  NEW  SITE  -  ENTER  P 

is  printed  in  the  I/O  area.  The  user  must  then  position  the  crosshairs 
at  the  desired  location  and  depress  the  keyboard  character  P.  A  second 
prompt  follows: 

ENTER  SITE  FUNCTION 

User  response  is  the  desired  two-character  site  abbreviation.  (See 
Table  E-I)  Following  a  valid  entry,  a  third  prompt  is  issued: 

ENTER  5-DIGIT  SITE  NUMBER 

Response  to  this  prompt  is  a  five  character  integer  number.  The  appropri¬ 
ate  symbol  is  then  displayed  if  a  unique  site  has  been  defined.  If  a 
duplicate  site  number  is  entered,  the  message 

DUPLICATE  SITE  NUMBER  -  TRY  AGAIN 

is  printed  and  the  user  is  afforded  another  opportunity  to  enter  a  unique 
site  number. 

If  a  duplicate  site  number  is  entered  and  the  location  of  the  newly 
added  site  corresponds  to  the  location  of  the  site  identified  by  the 
duplicated  number,  the  following  statements  are  issued: 

***  EXISTING  SITE  *** 

ASSIGNING  NEW  FUNCTION?  Y/N 
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The  resulting  user  response.  Yes  or  No,  then  either  assigns  the  already 
entered  new  function  to  the  specified  site  or  results  in  the  duplicate 
site  number  message  and  the  opportunity  to  re-enter  a  unique  site  number, 
(Figure  H-2) 


B.  CHANGE  - 

This  option  is  used  to  change  the  value  assigned  to  data  elements  in 
a  selected  site,  including  the  assignment  of  data  previously  undefined. 

When  the  CHANGE  option  is  specified,  the  crosshairs  are  displayed 
with  the  prompt: 


SELECT  SITE  -  ENTER  P 

The  crosshairs  are  used  to  select  the  site  at  which  parameter  changes  are 
to  be  made.  The  site  must  be  uniquely  identifiable  (see  PICK-ID). 

On  selection  of  a  valid  site,  a  numbered  list  of  site  parameters  and 
their  assigned  values  is  printed  in  the  I/O  area,  followed  by  the  prompt: 


ENTER  CHANGES 


The  user  may  assign  a  new  value  to  any  parameter  by  entering  the  parameter 
number,  an  equals  sign  (=)  ,  and  the  new  value,  followed  by  a  carriage,/-''^ 
return.  Multiple  changes  may  be  made;  a  zero  entry  for  the  parap^ter 
number  is  used  to  terminate  the  change  process.  / 

Changes  may  not  be  made  to  parameters  of  any  sites  in  the  New-Site 
buffer  or  at  any  time  while  all  sites  are  being  displayed. 


C.  CIRCLE  - 

This  option  is  used  to  identify  the  lethal  weapon  range  for  AAA  and 
SAM  sites  and  the  maximum  detection  range  for  EW,  FC,  and  GCI  sites  by 


86 


MICROCOPY  RESOLUTION  TEST  CHART 

NATIONAL  BURLAU  Of  STANDARDS  1963  A 


displaying  a  representative  range  circle  around  all  sites  within  the 
display  area.  Circles  from  some  sites  outside  the  display  area  will 
appear  if  the  site  is  near  the  display  boundary.  (Figure  H-2) 

This  option  remains  in  effect  (once  invoked)  for  all  subsequent 
displays  until  a  DISPLAY  or  RESET  option  is  specified.  For  clarity, 
circles  will  not  be  included  when  all  sites  are  being  displayed. 

D.  DELETE  - 

This  option  is  used  to  delete  a  site  from  the  display  area.  Either 
all  or  individual  functions  associated  with  a  site  may  be  deleted 
depending  on  the  plot  mode  at  the  time  the  option  is  specified. 

When  the  DELETE  option  is  specified,  the  crosshairs  are  displayed 
with  the  prompt: 

SELECT  SITE  -  ENTER  P 

The  crosshairs  are  used  to  select  the  site  to  be  deleted.  The  site  must 
be  uniquely  identifiable  (see  PICK-ID).  Program  response  is  to  place  a 
large  "X"  over  the  site  to  be  deleted  and  issue  the  following  query: 

DELETE  xx  FUNCTIONS  THIS  SITE?  Y/N 
where : 

xx  =  ALL  if  all  sites  are  currently  being  displayed,  or, 

xx  ■  The  abbreviation  of  the  site  function  when  a  unique  site  type 
is  being  displayed, 

A  Yes  response  to  the  above  query  will  completely  eliminate  the  site  from 
the  data  base  if  all  sites  are  being  displayed.  Only  the  function 


indicated  in  the  query  will  be  deleted  otherwise.  A  No  response  will 
negate  any  action,  (Figure  H-8) 

E.  DISPLAY  - 

This  option  is  used  to  select  the  site  type(s)  for  display  and 
possible  modification. 

When  the  DISPLAY  option  is  specified,  the  following  prompt  is 
issued: 

ENTER  SITE  FUNCTION  OR  "ALL” 

A  response  of  "ALL"  by  the  user  will  cause  the  screen  to  clear  followed 
by  a  new  display  of  all  sites  within  the  currently  defined  window.  Site 
records  in  memory  when  this  command  is  invoked  are  not  affected. 

A  particular  site  type  is  designated  for  display  by  entry  of  the 
site  type  abbreviation  (Table  E-l) .  When  this  occurs,  the  following 
functions  take  place  within  the  program,  if  a  different  site  type  is 
currently  displayed. 

(1)  The  New-Site  buffer  is  searched  and  newly  added  sites  whose 

type  is  being  replaced  are  added  to  their  appropriate  site  record(s). 

(2)  Site  records  being  replaced  are  sorted  in  site  number  order. 

(3)  The  replaced  site  records  are  written  to  mass  storage  and  the 

newly  specified  site  record (s)  are  read  into  memory, 

A  site  pair  is  designated  for  display  by  entry  of  the  abbreviation  for 
either  site  in  the  pair  followed  by  a  plus  sign  (+) ,  as  "AF+".  (Figure  H-4) 

If  surface-to-air  weapon  sites  (SA)  are  designated  for  display,  a 
second  prompt  is  issued: 


88 


ENTER  WEAPON  TYPE  (1  -  9)  OR  "ALL" 


If  "ALL"  is  entered,  all  AAA  and  SAM  sites  that  fall  within  the  defined 
window  will  be  displayed.  Otherwise,  valid  response  is  entry  of  an 
integer  from  1  to  9  which  identifies  the  desired  weapon  to  be  displayed. 
Weapon  types  1,  2,  and  3  are  AAA  sites  while  types  4  through  9  are  SAM 
sites. 

Any  combination  of  weapon  types  may  be  displayed  concurrently 
through  a  series  of  DISPLAY  options  and  weapon  type  specifications. 

The  primary  strategic  headquarters  will  appear  in  all  displays 
provided  it  is  defined  and  falls  within  the  current  window. 

F.  HELP  - 

This  option  is  included  as  an  aid  to  the  user  who  may  not  understand 
or  forget,  the  intended  OPTION  usage  or  required  response  to  a  particular 
prompt.  The  option  may  be  used  in  either  of  two  forms: 

If  HELP  is  entered  in  response  to  an  OPTION  prompt,  the  screen  is 
cleared  and  a  definitive  list  of  all  valid  options  and  a  site  symbol 
table  is  displayed.  The  previous  display  may  be  regenerated,  when  ready, 
by  entering  the  word  GO  in  response  to  the  prompt: 

TO  CONTINUE,  ENTER  -  GO 

printed  at  the  bottom  of  the  HELP  list.  Figure  H-12  is  a  copy  of  the 
display  when  a  HELP  option  is  specified. 

If  HELP  is  entered  when  the  program  has  requested  a  specific  input, 
such  as  site  function,  a  list  of  valid  inputs  or  an  explanatory  message 
identifying  the  form  of  input  required  is  printed  in  the  I/O  area. 

(Figure  H-4) 
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G.  LINK  - 


This  option  is  used  to  add,  delete,  and  visually  verify  communication 
links  between  the  various  sites.  Permissable  links  are  as  follows: 

EW  4 - ►  GP 

AF  4 - >  GC 

SA  4 - ►  FC  (for  Strategic  sites) 

SA  4 - ►  BA  (for  Tactical  sites) 

BA  4 - >  SB,  DV,  or  AH 

SB  4 - >  DV  or  AH 

DV  4 - >  AH 

Explicit  definition  of  linkages  from  GP,  GC,  and  FC  sites  to  Strategic 
Headquarters  is  not  necessary,  and  therefore  not  permitted,  as  this  task 
is  performed  implicitly  within  the  program. 

When  the  LINK  option  is  specified,  all  currently  defined  communica¬ 
tion  links  are  added  to  the  display.  This  mode  remains  active  for  all 
subsequent  displays  until  a  RESET  or  DISPLAY  option  is  invoked.  For 
clarity,  links  will  not  be  included  when  all  sites  are  being  displayed. 

The  crosshairs  are  then  displayed  with  the  prompt: 

SELECT  SITE  -  ENTER  P 

and  the  user  is  required  to  pick  one  of  the  two  sites  for  which  he  wishes 
to  add  or  delete  a  link.  When  this  action  is  complete,  the  same  prompt 
is  again  issued  and  the  user  se  acts  the  remaining  site.  Neither  site 
selected  may  be  currently  located  in  the  New-Site  buffer.  (Figure  H-5) 
Program  response  is  as  follows: 

(1)  If  no  link  existed  between  the  two  selected  sites,  linkage  is 
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established,  and  a  connecting  line  is  drawn  to  indicate  so.  A 
solid  line  denotes  a  primary  communication  link;  a  dashed  line 
represents  linkage  to  a  back-up  site. 

(2)  If  a  linkage  had  previously  existed  between  the  two  selected 
sites,  the  link  is  rescinded.  A  large  "X"  is  placed  at  the  midpoint 
of  the  connecting  line  to  indicate  this  action. 

(3)  If  the  selected  sites  are  not  paired  as  indicated  above,  an 
error  message: 

LINKAGE  NOT  PERMITTED 
is  issued. 

H.  LOCATE  - 

This  option  is  used  to  determine  the  X-Y  coordinates  of  locations 
within  the  display  area.  (Figure  H-4) 

When  the  LOCATE  option  is  specified,  the  crosshairs  are  displayed 
and  the  prompt: 

LOCATE  POSITION  -  ENTER  P 

is  printed  in  the  I/O  area.  When  the  required  action  is  completed,  the 
X-Y  position  of  the  crosshair  intersection  is  returned  as: 

X  -  23551.7 
Y  -  117.2 

I.  MOVE-SITE 


This  option  is  used  to  move  an  existing  site  to  a  new  location. 


When  the  MOVE-SITE  option  is  specified,  the  crosshairs  are  displayed 
and  the  following  prompt  is  issued: 

SELECT  SITE  -  ENTER  P 

The  crosshairs  are  used  to  select  the  site  to  be  moved.  The  site  must  be 
uniquely  identifiable  (see  PICK- ID) .  When  this  action  is  complete  the 
crosshairs  are  again  displayed  with  another  prompt: 

LOCATE  NEW  POSITION  -  ENTER  P 

The  crosshairs  are  then  used  to  identify  the  new  site  position. 

Program  response  is  to  draw  a  large  "X"  over  the  symbol  at  the  old 
site  location  and  place  the  appropriate  site  symbol  at  the  new  location. 
(Figure  H-3) 

J.  PICK-ID  - 

This  option  is  used  to  determine  the  site  number  of  a  selected 
site.  (Figure  H-4) 

When  the  PICK- ID  option  is  specified,  the  crosshairs  are  displayed 
followed  by  the  prompt: 

SELECT  SITE  -  ENTER  P 

User  response  is  to  place  the  crosshairs  over  the  desired  site  symbol  and 
enter  a  "P"  from  the  terminal  keyboard.  When  this  action  is  complete,  the 
program  returns  the  appropriate  site  number  as: 

SITE  NUMBER  -  12345 

provided  it  can  uniquely  identify  one  site  at  the  crosshair  intersection. 
If  it  cannot  do  so,  an  Informative  message 
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MULTIPLE  SITES  -  ZOOM  IN 


is  issued  and  program  control  is  returned  to  the  user.  If  no  site  symbol 
lies  beneath  the  crosshairs,  an  appropriate  informative  message  is  issued. 

K.  REDRAW  - 

This  option  is  used  to  selectively  generate  a  new  screen  display  of 
all  currently  active  sites.  Newly  added  sites  whose  type  is  different 
from  those  currently  active  will  be  omitted  from  the  display.  CIRCLE 
and  LINK  options  turned  on  at  the  time  the  REDRAW  option  is  specified 
remain  on. 

When  the  REDRAW  option  is  specified,  the  screen  is  erased  and  a 
completely  new  display  is  generated.  (Figure  H-5) 

L.  RESET  - 

This  option  is  used  to  "turn  off"  the  CIRCLE  and  LINK  options  and 
to  clear  the  New-Site  buffer. 

When  the  RESET  option  is  specified,  internal  program  switches  for 
CIRCLE  and  LINK  are  reset  such  that  neither  will  appear  on  subsequent 
displays  and  all  newly  added  sites  stored  in  the  New-Site  buffer  are 
sorted  into  their  appropriate  site  records.  (Figure  H-8) 


M.  RETURN  - 

SCALE  and  ZOOM  operations  may  be  intermixed,  but  only  to  a  depth  of 
eight  levels  (numbered  0  -  7) .  The  current  level  is  displayed  in  the 
small  block  in  the  upper-right  comer  of  the  menu  area.  The  RETURN 
option  is  used  to  scale  or  zoom  out  from  a  "blown-up"  display  area 
defined  by  prior  initiation  of  the  SCALE  or  ZOOM  options. 


When  this  option  is  specified,  the  prompt: 


ENTER  LEVEL 

is  issued  and  any  previously  defined  level  from  zero  through  the  currently 
effective  level  may  be  regenerated.  (Figure  H-10) 

N.  SCALE  - 

This  option  divides  the  display  area  into  16  equal  sections  and 
permits  the  user  to  select  any  one,  four,  or  nine  section  square  area  for 
enlargement . 

When  the  SCALE  option  is  specified,  a  4  x  4  grid  is  placed  over  the 
display  area.  Each  grid  has  an  associated  letter  identifier  (A  thru  R, 
160  excluded)  displayed  within  it.  The  prompt: 

ENTER  AREA 

is  then  issued  and  the  user  is  required  to  enter  either  a  letter  or  a 

letter-number  combination  to  indicate  which  area  he  desires  enlarged.  A 

<* 

letter-only  entry  will  cause  generation  of  a  new  display  which  includes 
only  the  indicated  square.  A  letter  followed  by  the  number  1,  2,  or  3 
(as,  62,  E3,  etc.)  will  cause  generation  of  a  display  which  includes  a 
1,  4,  or  9  section  square  area  with  the  upper-left  corner  corresponding 
to  the  lettered  square.  (Figure  H-6) 

O.  STOP  - 

Selection  of  this  option  causes  program  termination. 

When  the  STOP  option  is  specified,  all  site  records  are  updated  and 
sorted  with  respect  to  any  additions  remaining  in  the  New-Site  buffer. 


?=" 
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the  master  data  record  is  sorted,  the  display  screen  is  cleared,  and 
control  returns  to  the  operating  system. 

P.  ZOOM  - 

This  option  is  used  to  enlarge  any  arbitrarily  specified  section 
within  the  display  area.  The  section  is  identified  by  user  placement  of 
the  crosshairs  at  the  lower-left  and  upper-right  corners  of  the  desired 
area. 

When  the  ZOOM  option  is  specified,  crosshairs  are  displayed  and  the 
following  message  is  printed  in  the  I/O  area: 

POSITION  CROSSHAIRS 
LOWER  LEFT 

CORNER  OF  DESIRED  AREA 
ENTER  P 

When  this  action  is  completed,  a  second  message  is  issued: 

POSITION  CROSSHAIRS 
UPPER  RIGHT 

CORNER  OF  DESIRED  AREA 
ENTER  P 

Upon  completion  of  this  action,  a  new  display  is  generated  of  a  square 
area  delimited  by  the  larger  of  the  horizontal  or  vertical  differences 
of  the  crosshair  locations.  (Figure  H-2) 

To  zoom  or  scale  back  out  of  the  display  area,  a  RETURN  option  must 
be  specified. 
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APPENDIX  F 


UPDATE  STRUCTURE  DIAGRAMS 


The  UPDATE  program  consists  of  39  primary  functions  and  subroutines 
and  makes  use  of  many  additional  routines  from  the  CYBER  system  library 
and  the  TEKTRONIX  graphics  libraries.  This  appendix  consists  of  three 
diagrams  which,  together  with  the  baseline  diagram  of  Figure  8  in 
Chapter  V,  identify  the  primary  structure  of  each  of  the  major  segments 
in  the  program.  Figure  F-l  shows  the  structure  of  the  STARTUP  segment; 
Figures  F-2  through  F-5  are  a  series  of  diagrams  indicating  the  structure 
of  the  UPDATE  segment;  Figure  F-6  shows  the  structure  of  the  ENDUP  seg¬ 
ment  . 

In  order  to  maintain  readability,  only  the  primary  connections 
between  the  various  routines  are  shown.  Additionally,  only  the  highest 
level  of  interface  between  the  program  and  the  CYBER  and  TEKTRONIX  routines 
is  included.  A  complete  diagram  showing  all  interconnected  linkages 
between  all  of  the  routines  that  comprise  the  UPDATE  program  is  beyond 
the  scope  of  this  paper. 
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OPTION 
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OPTION 


Figure  F-4.  OPTION  Structure  Diagram  (Part  3) 
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APPENDIX  G 


UPDATE  COMMON  AREA  VARIABLE  DEFINITION 


APPENDIX  G 


UPDATE  COMMON  AREA  VARIABLE  DEFINITION 


The  UPDATE  program  contains  two  common  areas  which  provide  interface 
and  data  access  capabilities  to  the  various  routines  that  comprise  the 
program.  The  labeled  common  area,  GRAFIX,  contains  the  program  flags, 
switches,  counters,  and  constants  which  are  used  and/or  redefined  by 
different  routines  during  program  execution.  The  blank  common  area  con¬ 
tains  the  arrays  used  to  store  the  master  and  site  record  data  and  the 
New-Site  buffer.  This  appendix  will  identify  each  of  the  variables  and 
arrays  in  both  common  areas  and  provide  a  short  explanation  of  their 
purpose  and  usage. 


The  GRAFIX  common  area  contains  the  following  variables: 

NAS (8)  -  Contains  the  number  of  active  sites  for  each 

site  type  (1-7)  and  their  combined  total  (8). 

NTS (8)  -  Contains  the  maximum  number  of  sites  permitted 

for  each  site  type  (1-7)  and  their  combined 
total. 


NW0RDS(8)  -  Contains  the  number  of  words  in  each  mass 

storage  site  record  (1-7)  and  the  master 
record  (8).  NW0RDS(3)  is  unused. 

STACK (4, 8)  -  Used  to  store  boundary  data  for  up  to  8  SCALE 

or  ZOOM  levels.  Used  as  a  last-in,  first-out 
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NWC  - 


NWTPS(9)  - 


NSC  - 


TDHQ(2)  - 


SYMBHT  - 


NSINC(8)  - 


LH,  LP,  LX  - 


stack,  the  four  values  of  each  level  store  the 
lower-left  and  upper-right  coordinates  of  the 
display  window. 

A  counter  that  tracks  the  number  of  weapon 
types  (1  -  9)  being  displayed  when  SA  sites 
are  the  primary  record. 

Used  with  NWC,  this  array  contains  the  types 
of  weapons  being  displayed  when  SA  sites  are 
the  primary  record. 

A  counter  that  tracks  the  number  of  new  sites 
stored  in  the  New-Site  buffer  at  any  time. 

Contains  the  site  number  of  the  primary  (1)  and 
secondary  (2)  strategic  headquarters.  Set  to 
zero  if  no  headquarters  are  defined. 

Site  symbol  height.  The  length  of  the  side  of 
a  square  area  that  contains  each  site  symbol. 
Symbol  size,  defined  in  world  units,  remains 
constant  at  1.25%  of  the  x  distance  of  current 
display  window. 

Contains  the  number  of  each  site  type  (1-7) 
stored  in  the  New-Site  buffer  and  their  combined 
total  (8)  at  any  time  during  program  execution. 

TEKTRONIX  ASCII  Decimal  Equivalent  numeric  codes 
for  the  characters  H,  P,  and  X  respectively. 
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LEVEL  - 


KFLAG  - 


MCFLG  - 


MXL.MXR 


MSFILE 


ICR  - 


Used  with  STACK,  tracks  the  currently  displayed 
SCALE  or  ZOOM  level. 

Contains  a  series  of  switches.  Only  bits  zero 
through  4  (the  5  low-order  bits)  apply  and  are 
used  to  signify  the  following: 

Bit  0  -  Circle  switch  (1  =  ON,  0  =  OFF) 

Bit  1  -  Valid  option  selection?  (1*YES,  0  =  NO) 
Bit  2  -  Frame  re-draw  necessary?  (1  =  N0,  0  =  YES) 
Bit  3  -  Plot  all  sites?  (1=YES,  0  =  NO) 

Bit  4  -  Link  switch  (1  =  0N,  0  =  OFF) 

A  program  flag  used  when  SA  sites  are  displayed 
to  monitor  redrawing  requirements  for  the  frame 
and  menu,  previously  drawn  sites,  links,  and 
circles. 

MYB,MYT  -  The  screen  coordinates  of  the  lower-left 

(MXL,  MYB)  and  upper-right  (MXR,  MYT)  comers 
of  the  menu  area. 

Contains  the  logical  unit  number  through 
which  the  mass  storage  file,  or  data  base,  is 
accessed. 

Tracks  the  vertical  screen  position,  or  raster 
address,  for  non-overlapping  message  output 
in  the  I/O  area. 
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KTYP  - 


LTYP  - 


IXL, IXR, IYB, IYT  - 


K0DE(15)  - 


ISTATUS  - 


ACALT  - 


XHQ(2),  YHQ(2)  - 


Contains  the  number  of  the  currently  displayed 
primary  site  type. 


1 

*  EW 

3  =*  HQ 

5  =  AF 

7  =  SA 

2 

-  GP 

4  =  GC 

6  =  FC 

8  =  TA 

Contains  the  number  of  the  currently  displayed 
secondary  site  type.  Set  equal  to  zero  if 
only  primary  sites  are  displayed. 

The  screen  coordinates  of  the  lower-left 
(IXL,  IYB)  and  upper-right  (IXR,  IYT)  corners 
of  the  display  area. 

An  array  containing  site  and  weapon  type 
identification  codes.  The  code  is  a  binary 
representation  used  to  identify  each  of  the  15 
distinct  site  functions  in  the  PDDS. 

A  counter  which  tracks  the  number  of  times  each 
unique  data  base  has  been  modified  by  the 
UPDATE  program. 

The  altitude,  in  meters,  of  penetrating  air¬ 
craft. 

Contain  the  X  &  Y  coordinates  of  the  primary  (1) 
and  secondary  (2)  strategic  headquarters. 


The  blank  common  area  contains  the  following: 


REC(4000)  -  The  array  through  which  data  is  transferred 

between  the  UPDATE  program  and  mass  storage. 

IDNUM(500)  -  Contains  the  site  numbers  of  all  sites  in  the 

currently  defined  data  base.  The  numbers  are 
assigned  in  ascending  order. 

X(500),  Y(500)  -  Contains  the  X  &  Y  coordinates  of  the  site 

whose  number  is  contained  in  the  corresponding 
word  in  IDNUM. 

IFUNC(500)  -  Contains  the  coded  site  function(s)  of  the 

site  whose  number  is  contained  in  the 
corresponding  word  in  IDNUM. 

NEWSITE(2,50)  -  The  New-Site  buffer.  Permits  a  maximum  of  50 

sites  of  all  types  to  be  added  before  they  must 
be  sorted  into  their  individual  site  records. 
Each  site  is  identified  by  a  site  number  (1) 
and  a  coded  function  (2). 

The  dimensions  of  all  arrays  in  blank  common,  except  NEVJSITE,  may  be 
modi  *ed  to  any  required  size  with  no  corresponding  impact  on  program 
execution.  If  such  modifications  are  made,  however,  care  must  be  taken 
that  program  loading  requirements  do  not  exceed  available  memory. 
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APPENDIX  H 


SAMPLE  UPDATE  DISPLAYS 
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APPENDIX  H 


SAMPLE  UPDATE  DISPLAYS 


Earlier  chapters  and  appendices  have  described  the  design,  implemen¬ 
tation,  and  operational  characteristics  of  the  PDDS  with  almost  all 
emphasis  pointing  toward  graphic  display  of  the  site  dependent  data.  The 
figures  in  this  appendix  are  copies  of  actual  UPDATE  displays  obtained 
through  the  use  of  a  TEKTRONIX  4026  hardcopy  unit.  The  figures  are 
sequenced  from  program  Initiation  through  a  series  of  displays  and  are 
designed  to  show  the  largest  variety  of  unique  UPDATE  option  and  I/O 
communication  characteristics  possible.  Some  duplication  could  not  be 
avoided.  The  crosshair  locations  on  Figure  H-2  have  been  hand-drawn. 
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Figure  H-12.  HELP  Option 
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